This message was deleted.

do you do any

dependsOn

in your LOB apps?

like... a LOB app can depend on something in another stack?

oh I see, so these are using stack references?

yes... we build the k8s cluster in an app and save the kubeConfig ... then the core resources gets a stackReference to the cluster app kubeConfig and uses it to install core resources... then the LOB pulumi apps get the same StackReference and use the kubeConfig to install LOB apps

ah, so you're talking about situations where you destroy the stacks in the wrong order?

yes

got it, if you file an issue for this we might be able to put the destroy behind an env var

We delete the parent without deleting the dependent children and then we have to manually go clean up the children

the previous behaviour of the Kubernetes provider was to assume if the API was gone, the services were gone. We reverted that behaviour because there are instances in which you get network timeouts and it could cause the state to be destroyed but the apps still exist. I think if you know the API has gone and want to clear your state, you should be able to do that - which I tnink would help you, right?

If an app took a dependency on a .kubeConfig and then detect that the .kubeConfig is gone or has changed (for the same StackReference), when we do a

pulumi up

or

pulumi destroy

it simply clears out the state first and then proceeds is what I think I want.