it seems like depends_on is what I need, but I’m n...
# general
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
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.
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
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.
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
You should try to avoid using flags like that. That leads to accidentally deleting prod.
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
Sounds sensible.
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