Got the rest of the deployment up without the

BucketNotification

, 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.

This is likely created by your EKS, you’ve probably created a service of

type=LoadBalancer

which creates an associated secuyrity group

@billowy-army-68599 If that's the default, then that's probably what happened. Could you clarify a bit why that would keep Pulumi from being able to bring it down, though? If it's relevant, I was getting an error trying to bring down this security group before any of my charts/releases were deployed, so this service must have been created by the

eks.Cluster

, right? Any recommendations for how I can get rid of it now and in future?

you do need a loadbalancer yes. The way to avoid this is to set dependsOn in your services to avoid the cluster being deleted before the helm chart

@billowy-army-68599 Right on, so the

provider

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.

it is creating the dependency link, but it’s not awaiting the deletion of the helm resources. Once the chart is destroyed, it deletes the cluster. However, the helm resources might not have finished deleting yet

@billowy-army-68599 I was able to bring the cluster fully up with only some deploy errors for two of the charts that weren't predicated on Pulumi. Unfortunately, ringing it down is still sticking on the same security group. Gonna destroy whatever's holding it up manually. Can also confirm that the Pulumi output shows the

Cluster

as deleted, which I also see in the console. Will rerun and see if it happens again.