Hi, I was hoping to dig out a value from a file stored on disk in one of my services via a simple

run task

that does a

cat

of the file, then capture this via task output.log and I can then use this as inputs for other tasks etc. It turns out that the task script is run in a separate container, that does not have the required volume mounted, and hence the approach fails. Any tips to accomplish what I want? Any details on how the task container is specified to run? Does it run as a separate container in same pod or something like that?

Hi @tall-greece-98310, are you using

volumeMounts

by chance or do you have a sanitized

garden.yml

you can share? If the former,

volumeMounts

for Tasks suffer from a bug we're hoping to take a second look at after our next Garden release: https://github.com/garden-io/garden/issues/1766

yes, I am using a PVC in a stateful set. In general I'm starting to think taht the way a separate pod is launched isn't going to work well for all types of tasks. I expected tasks to be run more via

kubectl exec

in the already existing pod/container. Launching a new one will have lots of cases where it'll be cumbersome. One example: another case of mine the StatefulSet has pod-antiaffinity to not scheulde vault on same node. I only use 1 replica in dev so no issue, the affinity has no impact. But then the task inherits the same rules and can't launch as I also only use 1 node in my dev KinD setup. So intuitively I'd prefer to run tasks inside existing pods/containers, not launch new ones. I'm setting up things in parallel in devspace as a comparison and it uses that approach and so far it wins out for dev convenience. I just add a few bits on top of the prod image that is useful for dev, then run these things inside the actual containers and there are no surprises.

This is fantastic feedback, thank you! We'd hate to lose you to Devspace. In general, I think we're the far more powerful option but happy to jump on a call with you at least to understand your experience (without selling you)

don't have anything easy to share. but just in general taking a copy of a pod from a stateful set isn't logical - e.g. even if the volume mount bug was fixed I wouldn't expect to be able to mount the same disk in a read-write fashion in more than 1 pod. I understand that in general creating an "external to the service" pod that uses APIs etc is doable, but often it's a lot more work than just poking at things in the "real" pod. especially for dev work I don't want the complexity of e.g. needing to setup admin users that are externally exposed just for the case of being able to perform some admin action via API. and in some cases it's not doable, I actually want to save the content of a file in a stateful pod volume as a garden task output. It's as simple as

cat /path/to/file

and using

output.log

for the task - but the task wont ever be able to cat that file from outside the actual stateful set pod. I agree that the higher level concepts of garden are powerful, but I think we need some lower level escape hatches as well. E.g. a task can run as a separate pod or as

kubectl exec

in the existing pod. that kind of thing.

Hey @tall-greece-98310 thanks a lot for reporting this, I'm pleased to say that this feature is now in a short-term roadmap for Garden 0.13 which will make possible to select if tests/tasks will be run against a new pod or into an existing one. https://github.com/garden-io/garden/issues/3922