https://pulumi.com logo
Join Slack
Powered by
it seems like depends_on is what I need, but I’m n...
# general
g
it seems like depends_on is what I need, but I’m not sure if the behavior of that means pulumi will wait and require that resource to be healthy or not
l
It will wait for it to be deployed (have an ID). It won't wait for a health check, unless you have a provider that doesn't mark a resource as deployed until its health check passes.
This is doable, but afaik it's not part of the standard provider.
g
yeah it seems unkubernetes-ish anyway to do something like this… unfortunately we have a few deployments that have a predeploy stage. When we were using krane we got away by having a separate out-of-band deployment of JUST the Job resource, and if that didn’t become healthy the pipeline would bail and not deploy the rest of the resources..
As you said, I might have to extend the provider or the Job resources at a minimum to consider health check before marking it as deployed (having an ID)
that seems hacky tho
l
If your previous deployment strategy worked, I would reproduce it, if possible. 2 Pulumi projects, one for the pre- and one for the regular-deploy. Start one when the other finishes / passes health check.
And if you do it using automation-api, you can even do the whole thing in one index.ts, and have the health check done in between the two Pulumi programs.
g
I was also thinking of using the same project, but have a feature-flag for predeploy vs non-predeploy and have 2 separate stacks.. not sure if that would be feasable
l
You should try to avoid using flags like that. That leads to accidentally deleting prod.
g
yeah
this seems like a good starting point for this I think
👍 1
2 separately managed pieces of code, tied together with automation API and 2 separate stacks to track accordingly
I’ll have to pick one of the stacks/project pieces to “own” the namespaces and imagePullSecrets we auto-create, but other than that I think this will at least coordinate the pulumi run better
I mean, hypothetically it would be acceptable to deploy the predeploy pods in a separate namespace if I had to, which might be even cleaner
🤷
that way predeploy has its own k8s namespace altogether and it’s very clear they are 2 independent / isolated workflows
l
Sounds sensible.
✅ 1
g
thanks for talking through this. I’m going to give the automation API piece a try and see if it solves the requirement. But now it’s late and dinner time, so I’m done for the day. 👋 partyk8s
3 Views
Open in Slack
PreviousNext
Powered by