salmon-musician-3633304/24/2023, 1:05 PM
, but it still doesn't want to come down cleanly—somehow this
still doesn't want to go away:
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
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: ...
hasn't brought it in. Would also be happy to have any suggestions on what toggles I should be setting with
so that it upgrades cleanly; after I got the cluster up the first time, I ran
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-6859904/24/2023, 1:59 PM
which creates an associated secuyrity group
salmon-musician-3633304/24/2023, 2:30 PM
, right? Any recommendations for how I can get rid of it now and in future?
and is there a way to avoid having it? I'm deploying Istio Ingress as well.
billowy-army-6859904/24/2023, 2:55 PM
salmon-musician-3633304/24/2023, 4:35 PM
is not implicitly creating the dependency link. Ok, I've added a
declarations and a
to all of my `helm.v3.Release``s. I suspect the
dependsOn: [eksCluster, <relevant namespace>]
dependency for the `Release`s is redundant, but guess it can't hurt.
billowy-army-6859904/24/2023, 4:45 PM
salmon-musician-3633304/24/2023, 11:05 PM
as deleted, which I also see in the console. Will rerun and see if it happens again.