When destroying a stack, shouldn’t the Kubernetes ...
# generalb
busy-air-16359
07/02/2019, 2:50 PMWhen destroying a stack, shouldn’t the Kubernetes provider be destroyed first and then AWS? Right now, the EKS worker nodes are deleted first, and then obviously no k8s operator can cleanup anymore
b
busy-umbrella-36067
07/02/2019, 2:56 PMThe control plane is managed by Amazon, not having worker nodes should’t affect k8s operations
b
busy-air-16359
07/02/2019, 3:04 PMsure, but a lot of resources are created by kubernetes operators these days
busy-air-16359
07/02/2019, 3:04 PMif you kill the operator by removing the worker nodes, there is no way it can clean up its resources
b
busy-umbrella-36067
07/02/2019, 4:03 PMI hadn’t thought of that, I think you could simulate the behavior you want by adding
dependsOn: this.defaultNodeGroupbusy-umbrella-36067
07/02/2019, 4:04 PMI’d be interested to hear if that manages to delete the K8S Resources deployed with the provider before it deletes the worker asg
b
busy-air-16359
07/02/2019, 4:41 PMgood point, I’ll try adding that
busy-air-16359
07/02/2019, 4:42 PMI thought pulumi would figure out the dependency automatically, because the k8s provider is created from the aws/eks provider
busy-air-16359
07/02/2019, 8:05 PMthat did the trick, thx
👍 1