https://pulumi.com
Join Slack
This message was deleted.
# kubernetes
s
This message was deleted.
g
dependsOn
is the answer for now, but you also might want to consider using an 
initContainer
for tasks like DB migration instead of a 
Job
b
We are running multiple deployments that all depend on the same database, so an 
initContainer
is not a great option. This also would require running the database migrations every time a pod restarted, which I wouldn't like very much. 🙂
Thanks for the reply! Is there a feature request open like what I proposed above? Do you think I should open one?
g
I don’t know of an open issue, but the pulumi/pulumi repo would be the place for it
If you do want to pursue the 
initContainer
route, you could make the migration script idempotent and add it to all relevant Deployments. So the script would run each time, but would be a no-op if the version already matched (or similar)
We’re using something along those lines for our on-prem SaaS
b
It's idempotent, but I really want a LOT more control than that. If the migration fails for any reason, I really, really don't want my entire production infrastructure limping along repeatedly trying to migrate.
👍 1
Additionally, having it as its own 
Resource
means I can run it on its own, if we have a tricky deploy.
b
we came to the same conclusion and wrote a dynamic provider for schema migrations
3 Views
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by