Hello, TLDR: Using a "task" for a database migration container is not a good option as there is no automated way to run the task without having something depend on it explicitly. Using a container dies shortly after the command runs correctly, but garden complains because it dies quickly. I have a service (container) that deploys database X, let's call it "database" I have another service (container) that does the database migration, let's call it "migration" "migration" depends on "database" naturally. If I use task for the migration, I have to run it manually which is not desired, I need this to run always when deployed. If I use it as a container, it works well, but the container dies too fast and garden complains about it, with the "BackOff - Back-off restarting failed container" error. But the container did what it is supposed to do. Is there an option to tell garden not to complain if the container stops too early? Or is there an option to get the task to run automatically? We also had many other use cases where we wanted the task to run automatically, I think this would be a desired feature. Thank you.

Hello @aloof-lamp-69262 thanks a lot for posting this. Just one question, are you adding dependants to your tasks by any chance? According to the docs

"Tasks that have dependents (i.e. something that depends on them) are run automatically by Garden. For example, if a service depends on a task being run before it is deployed, then Garden will automatically run that task before deploying the service. Other tasks will need to be run manually."

So maybe following this example might help? https://docs.garden.io/using-garden/tasks#database-migration

No, in this case, we don't have anything that can depend on this task really, it is just something that runs after the database starts. Alternatively if a task can have an option to run "after" a parent, and not "before" that might help too, but I imagine it might become confusing. To make the parent depend on it, but it runs after the parent...

Oh, I see what you mean now. A little 🐔 and the 🥚 issue. Is this

migration

service a Node application that runs

npm migrate:up

or something like that? Or it's just a set of scripts that you are running after the database is already up and running?

It's a custom set of scripts yes. not node specific

Oh I'm glad you guys are enjoying Garden 🌸 . That workaround it's good but definitely not ideal as makes you waste 2 precious minutes everytime you deploy it. Let me try to experiment a little bit with a custom postgres container in my local trying to inject some scripts and see if I can reproduce your scenario.

Thanks! appreciate it.

This is actually a neat idea, I love emojis @quaint-dress-831

Cool 🙂

The first try works fine but subsequent just fails, what's happening is that Kubernetes obviously tries to keep the pod alive after finishing the task, because these are not init containers or jobs that are supposed to finish either successfully or not.

Right

Basically going to scalate this one with the OSS Developers to see if they have any other recommendation about what could we use to run those migrations automatically. And also create a Github Issue to document the need of a Garden Job or some sort of module like that.

Nice, can you link the issue on github so I can follow that please, when it's created.

Yeah, for now the only solution that I can think of is creating a tiny helm-chart that has the postgresql database and an init container that runs the migration everytime there's a deploy

you mean instead of using "container" as module type, use "helm-chart"?

Correct, but I believe it might be too much work to do the helm chart for that. Let's see if @quaint-dress-831 / @swift-garage-61180 could help us debug this one!

Cool.

Sent you a couple of examples by DM so you can take a look, I'll be submitting this as an issue with the dependencies objects, as the setup task should run successfully and automatically if the dependencies are well set between services/tasks.

Thank you

@quaint-dress-831 documented this issue in this repository: https://github.com/ShankyJS/garden-migrations-postgres Hopefully you can take a look as I tried two different options to provide a good workaround for this issue but wasn't able to find a good solution. (Feel free to run both examples, each of them have a tiny README to guide through the thought process I followed to implement them).

We could definitely open this as an issue. We also would benefit from badges so people can show they're building with Garden 💪

If we could support jobs in the container modules the approach I documented in my repository (using-modules folder) would work really easily, definitely a nice to have for future versions. I think @aloof-lamp-69262 was able to solve the issues by adding a sleep to prevent the container from dying, but definitely a better solution would be leveraging a helm/kubernetes container instead

Once the core team ships our next-gen release, I think it's absolutely something worth addressing providing it's still an issue in 0.13

Thanks for that, for now the 2 minute sleep is preventing the ill effects, but it's good to know that other options such as kubernetes or helm exists, in case we want to try them out as an alternative.