Pulumi doesn't fully check for dependent objects?

[mausch]

What happened?

I tried deleting an AWS security group with Pulumi. This security group has 2 network interfaces associated so it can't be deleted directly.

If I go to the AWS console and try to delete the security group, it tells me right away that it can't be deleted and why (with links to the network interfaces)

When trying to delete it with Pulumi, it takes about 10 minutes to fail saying it has dependent objects and it doesn't say what the dependencies are.

This seems related to pulumi/pulumi#8005 (comment) but the focus there seems to be about failing fast (which is valid and would help here) whereas it seems to me that Pulumi just isn't checking dependencies correctly (at least in this specific case)

Example

As described above

Output of pulumi about

CLI          
Version      3.88.0
Go Version   go1.21.1
Go Compiler  gc

Plugins
NAME        VERSION
aws         6.5.0
aws         5.31.0
eks         1.0.4
kubernetes  4.4.0
kubernetes  3.30.2
nodejs      unknown

Host     
OS       ubuntu
Version  22.04
Arch     x86_64

This project is written in nodejs: executable='/nix/store/x8vrc1c6r8nn454whr99bxc5hdy5ybjf-nodejs-18.18.0/bin/node' version='v18.18.0'

Current Stack: develop

TYPE                                      URN
pulumi:pulumi:Stack                       urn:pulumi:develop::infra::pulumi:pulumi:Stack::infra-develop
pulumi:providers:aws                      urn:pulumi:develop::infra::pulumi:providers:aws::default_6_5_0
aws:opensearch/domain:Domain              urn:pulumi:develop::infra::aws:opensearch/domain:Domain::elevate-develop-os2
aws:opensearch/domainPolicy:DomainPolicy  urn:pulumi:develop::infra::aws:opensearch/domainPolicy:DomainPolicy::elevate-develop-os2-policy
aws:ec2/securityGroup:SecurityGroup       urn:pulumi:develop::infra::aws:ec2/securityGroup:SecurityGroup::eks-api


Found no pending operations associated with develop

Backend        
Name           mauricio-Precision-Tower-5810
URL            s3://elevate-pulumi-nonprod
User           mauricio
Organizations  
Token type     personal

Dependencies:
NAME                VERSION
@types/node         14.18.35
js-yaml             4.1.0
ts-node             10.9.1
typescript          5.2.2
@pulumi/aws         6.5.0
@pulumi/eks         1.0.4
@pulumi/kubernetes  4.4.0
@types/js-yaml      4.0.8

Pulumi locates its logs in /tmp/nix-shell.8JFcqI by default

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[justinvp]

This security group has 2 network interfaces associated so it can't be deleted directly.

@mausch, are the 2 network interfaces managed by Pulumi? Is there a dependency relationship in Pulumi with the 2 network interfaces depending on the security group? If so, when doing a pulumi destroy, the 2 network interfaces will be deleted first, before the security group.

[mausch]

Hi Justin!

I think there's a misunderstanding about what the issue is. The point is, if AWS can immediately say that the resource cannot be deleted and the reason, why does it take Pulumi ten minutes to do the same?
Regardless of whether there's a dependency relationship in Pulumi, surely Pulumi can check for these things?

[Frassle]

Regardless of whether there's a dependency relationship in Pulumi, surely Pulumi can check for these things?

We possibly could, but firstly it would require scanning your entire cloud account for dependencies on every update which would be horrifically slow, secondly I'm not actually sure that every cloud provider even providers the APIs to do this sort of listing of all possible resources, and thirdly even if they did it's a significant increase in what is required to support a cloud API as a Pulumi provider.

For all those reasons we only track what's in state, and rely on the cloud provider to error if state has drifted as it can do it more reliably and faster.

[justinvp]

This seems to be more of a request for enhanced behavior in the AWS provider. Therefore, I'm going to transfer the issue to the pulumi-aws repo. Although, the AWS provider uses the Terraform provider, so this would likely need to be addressed in the upstream provider.

[mausch]

We possibly could, but firstly it would require scanning your entire cloud account for dependencies on every update which would be horrifically slow

Pretty sure that not every single object type in AWS can depend on a security group.
Maybe it cannot be done generically but it could be tackled on a per object type basis.
So perhaps it could be done for security groups first, at least (feel free to change the issue title).
AWS's instantaneous response suggests that there's no need for an actual scan in this case.

[mattbdc]

Seeing same. 15minutes for this:

 Type                      Name      Status                  Info
 pulumi:pulumi:Stack       main-dev  **failed**              1 error

• └─ aws:ec2:SecurityGroup sg-db deleting failed 1 error

Diagnostics:
aws:ec2:SecurityGroup (sg-db):
error: deleting urn:pulumi:dev::main::aws:ec2/securityGroup:SecurityGroup::sg-db: 1 error occurred:
* deleting Security Group (sg-065ac06f38e5546ad): DependencyViolation: resource sg-065ac06f38e5546ad has a dependent object
status code: 400, request id: 05e9c349-ee59-435f-a3b4-0247df9d8e8e

pulumi:pulumi:Stack (main-dev):
error: update failed

Resources:

Duration: 15m6s

What happening in those 15minutes?