salmon-musician-36333
04/24/2023, 1:05 PMBucketNotification
, but it still doesn't want to come down cleanly—somehow this SecurityGroup
still doesn't want to go away:
aws:ec2:SecurityGroup (...):
error: deleting urn:pulumi:dev::...::eks:index:Cluster$aws:ec2/securityGroup:SecurityGroup::...: 1 error occurred:
* deleting Security Group (...): DependencyViolation: resource ... has a dependent object
status code: 400, request id: ...
Is there a way to get Pulumi to find the dependent instances, or, failing that bring down the deployment dirty (delete what it can until it's only getting these kind of errors)? I assume if the dependent it's referring to were in the state file then it would be trying to bring it down first anyway, and pulumi refresh
hasn't brought it in.
Would also be happy to have any suggestions on what toggles I should be setting with helm.v3.Release
so that it upgrades cleanly; after I got the cluster up the first time, I ran pulumi up
again to see if it would confirm that it's in the desired state, but then got upgrade failures for several of my charts.billowy-army-68599
04/24/2023, 1:59 PMtype=LoadBalancer
which creates an associated secuyrity groupsalmon-musician-36333
04/24/2023, 2:30 PMeks.Cluster
, right?
Any recommendations for how I can get rid of it now and in future?LoadBalancer
and is there a way to avoid having it? I'm deploying Istio Ingress as well.billowy-army-68599
04/24/2023, 2:55 PMsalmon-musician-36333
04/24/2023, 4:35 PMprovider
is not implicitly creating the dependency link. Ok, I've added a dependsOn: eksCluster
to my k8s.v1.core.Namespace
declarations and a dependsOn: [eksCluster, <relevant namespace>]
to all of my `helm.v3.Release``s.
I suspect the eksCluster
dependency for the `Release`s is redundant, but guess it can't hurt.billowy-army-68599
04/24/2023, 4:45 PMsalmon-musician-36333
04/24/2023, 11:05 PMCluster
as deleted, which I also see in the console. Will rerun and see if it happens again.