https://garden.io logo
#🌱|help-and-getting-started
Dig out a value from a file on disk in a service via a task?
# 🌱|help-and-getting-started
t

tall-greece-98310

03/06/2023, 11:02 AM
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?
q

quaint-dress-831

03/07/2023, 2:25 PM
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
t

tall-greece-98310

03/08/2023, 9:08 AM
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.
q

quaint-dress-831

03/09/2023, 1:47 PM
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)
@bright-policeman-43626 let's talk process on how we escalate feedback like this to the open source team so our users are heard. Currently, I think it's easy to get lost in issues: I think it'd be a good idea to be able to keep looping back to papercuts like these until they're improved or we have alternatives ready.
@tall-greece-98310 if you have any
garden.yml
to share with us, it's just a good springboard to demonstrate to others. Otherwise I'll write one up myself that fits your description.
t

tall-greece-98310

03/09/2023, 6:23 PM
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.
b

bright-policeman-43626

03/13/2023, 5:45 AM
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
Hey @tall-greece-98310, not sure if you noticed but we have shipped Garden Bonsai (0.13) that includes the feature I suggested above, I think this will fix the issues you where having before, Would you be open to have a tiny pairing session with me going through your previous issues and see if this new release could help with that? Also would love to hear your feedback with Garden! The release was announced here -> #1078632412457734264
5 Views