TBH, I am almost giving up and just using Command.local to create command script resources that create, update, and delete my various helm charts.

In my experimentation with Command.local you’ll almost certainly run into other blockers. For example, you cannot provide a k8s provider to Command.local, so you’ll end up needing to export the kubectl context into the environment for Command.local - and that drives up the complexity a fair amount.

dependsOn broadly says: “wait until this object exists”. In the example above

crdb

exists when it is defined, so that passes the dependsOn check immediately. So you want to depend on something that takes time. I think the rationale is that

status

isn’t ready until the install has occurred.

but I want to caveat this with: I’ve not tried this. I’m just hypothesizing around what I do understand about

dependsOn

.

I guess I'm failing to understand what

crbd.status

is and where it's coming from

@full-eve-52536 it’s an output of

helm.Release

; additionally it’s Resource itself, so you can

dependsOn

it

Thank you for explaining that. That's an interesting theory we'll have to try. We install about 5 or 6 helm charts using

Release

as part of our stack and almost everytime we run

pulumi up

We get

the server could not find the requested resource

The whole CRD world is so powerful, but also really complex. Consider the example of: my-crd-package-v1 my-app-package-v1 if

my-app-package-v1

depends on CRDs defined in

my-crd-package-v1

, how can you upgrade to

my-crd-package-v2

without breaking

my-app-package-v1

? So, typically, you end up with

MyCRD-V1

and

MyCRD-v2

, etc, and then the app package can decide which one it wants to implement.

@full-eve-52536 excuse my sidebar thought! Regarding your timing issue, I’d start by installing the CRDs by hand to get a sense of how long helm spends at that stage. This may require a demo k8s cluster, etc. Perhaps updates of them take a while, etc, etc.