Are you using that security group anywhere outside of this stack? For example, did you create another security group that refers to this one? Did you assign it to instances or other compute outside of the stack? If so, I believe AWS will prevent you from destroying it until you have destroyed those dependent objects.
If not, I would possibly need to see more details of what got deleted and when - did the AutoScalingGroup get deleted successfully? More generally - what things are still left in your stack when you saw this? Feel free to DM me if needed.
01/17/2019, 10:20 PM
Should I be able to track it down in the AWS console? Maybe I can suss out if something/someone else used the same item
We are having to work through some of our own development issues because we were a bit spoiled.... when using GCP we each had our own project to develop against
no such luck in AWS
01/17/2019, 10:25 PM
Yeah - unfortunately this direction of link isn't discoverable from AWS console or APIs as far as I'm aware.
Its possible it's related to dependencies in the Pulumi project being wrong (possibly in the EKS package). If you can share the full deployment status that might help pinpoint a potential issue with something getting deleted before something that it depends on.
Curious - if you re-run the destroy now, does it work? That could also suggest some eventual consistency bug in AWS - we've seen that sort of thing before - though usually the underlying providers have compensating logic for that.
01/17/2019, 10:28 PM
re-running but I think it's going to fail
fixed it but manually
there was an orphaned network interface that the sg was tied to
deleted that interface and it was able to be destroyed
01/17/2019, 11:16 PM
Great. Can’t explain exactly how you got in that state - but glad you were able to fix it. If you see this again via Pulumi, would love to dive deeper.