No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

no this isn't possible at this time, would love to hear your use case. you can achieve this by deleting the resource from state using `pulumi state delete` and then rerunning your `pulumi up`, which will create a new resource entirely

For sure, I'm re-issuing a new SSL certificate for my google cloud load balancer.

I have to specify all the various domains, so when I add a new service to my deployment or add another TLD tenant to our service, we end up having to reissue our certificates for each TLD.

Which Pulumi does an amazing job at, except... That it deletes the old one and our service goes down while the new one is still provisioning.

It would be neat if there was an `Immutable = true` option for resources which just creates a new one the moment any properties change.

Or perhaps

```Immutable = 
{
    "PropertyOne",
    "PropertySeven",
},```

are you specifying an explicit name for your certificate?

if you use autonaming on the resource, you'd get a create before delete which would avoid this

I think the problem is the create resolves before the resource is ready.

(pulumi doesn't end up exposed to the full lifecycle)

A new cert will go into this state, which is considered provisioned, but is technically not in a viable state.

I guess what I'd like is to be able to have my old cert linger and I'm even 100% okay with manually deleting it.

ahhh, yeah could you open an issue for that, with a repro?

short of deleting the cert from the state, there's not much else that can be done, I think

So... Crazy thought, but what if there was some way to have pulumi be told to do that delete based on a name change?

Like "orphan this resource when the name property changes"

It'd be 100% explicitly opt-in.  But I bet it might come in handy in other scenarios.

Is `deleteBeforeReplace` and/or `replaceOnChanges` what you're looking for?

<https://www.pulumi.com/docs/intro/concepts/resources/#deletebeforereplace>

<https://www.pulumi.com/docs/intro/concepts/resources/#replaceonchanges>

Or to be very very specific: "orphan on replace"

<@UCWG26BH7> <https://github.com/pulumi/pulumi/issues/8450>

It would also be handy for things that providers version themselves. One that jumps to mind is AWS EC2 image builder recipes. If I'm adding v2 of recipe X, I'd quite like to orphan-and-unmanage v1 of recipe X...

This is an interesting idea. <@UCWG26BH7> could you open an issue in pulumi/pulumi with a summary of this thread?

<@U84HBHXS8>: <https://github.com/pulumi/pulumi/issues/8450>

FWIW I think cloudformation calls this "DeletionPolicy: Retain"