This message was deleted.
# general
s
This message was deleted.
b
This is likely created by your EKS, you’ve probably created a service of
type=LoadBalancer
which creates an associated secuyrity group
s
@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?
Also... Do I need this automatically created
LoadBalancer
and is there a way to avoid having it? I'm deploying Istio Ingress as well.
b
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
s
@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.
b
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
s
@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.
Hey mate, just wanted to check back in here and say thanks, deployment up/down seems to be working smoothly now.
🙌 1