hmmm, is the following (in screenshot) a pulumi bug?

I don’t work for pulumi, but I would agree, this should be part of the pulumi provider. I would open an issue for this on GitHub. There are a lot of these types of issues that I think pulumi should solve on the behalf of the user.

hmm this must be the most basic operation with the most basic resource (aws ec2), hard to believe that it is some kind of a new bug

you might want the

deleteBeforeReplace

option?

The point is this shouldn’t be necessary to specify.

I think that's arguable - pulumi knows how to create a resource. And it knows how to delete a resource. And if a specific update requires a recreate - it defaults to creating the new resource before deleting the old resource in order to protect your infrastructure in the event that the new resource creation fails. This only becomes an issue in scenarios where only 1 instance of the resource may exist - such as here, or an SSL cert, or a DNS record, etc.. Now pulumi could make the provider aware of those kinds of resources, and I think there is a valid argument for that, but would that make pulumi less explicit and add risk of accidental deletion? There is cost to be weighed there

It’s not that pulumi should act upon everything without verification, but that code should not need to be changed temporarily in order to work with these types of scenarios.

ah -

deleteBeforeReplace

would not be a temporary change. You would always leave it

true

on those resources

For example:

Pulumi has detected that the interface $x is currently attached to an instance $y that is scheduled for replacement. Do you wish to detach the interface in order to replace the instance?

this is an artefact of the upstream EC2 API, it's expected behaviour. it's called out in the upstream provider but we don't parse that into our docs https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance#network-interfaces you have to use this resource to attach the interface instead: https://www.pulumi.com/docs/reference/pkg/aws/ec2/instance/#instancenetworkinterface We are limited in what we can do with upstream providers, which is why we're building native providers. The AWS provider is in the works right now

Maybe in this particular case it makes sense (or doesn’t), but there are other scenarios where this is been an issue (requiring

deleteBeforeReplace

)

not all of them will be fixed from the get go, but they will be fixable. Again, many of these issues are because the upstream API is immutable in some way. there's such a large surface area, but we'll be able to work around the corner cases like this and provide better error messages

Of course, nothing will be perfect from the get go. That’s good to hear.

@boundless-angle-56560 let me know if my explanation makes sense, if you need some code I can provide an example

@billowy-army-68599 understood, I will use that parameter. If that's of any value, my opinion is that creating a second resource before deleting old one sounds pretty tricky when it comes to semantics. I think it cannot work as expected in many scenarios as resource often holds something that is exclusive (whether it is a static IP or a network interface like in my case) and one would need an advanced logic to resolve whole situation.

@boundless-angle-56560 disregard what I said about deleteBeforeReplace in this specific EC2 scenario and checkout the links @billowy-army-68599 provided, one of which was a terraform link

aha, sorry I didn't scan through all responses 😳