https://pulumi.com
Join Slack
This message was deleted.
# general
s
This message was deleted.
b
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
a
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
Copy code
Immutable = 
{
    "PropertyOne",
    "PropertySeven",
},
b
are you specifying an explicit name for your certificate?
a
Yes.
I hash up all the subdomain names.
b
if you use autonaming on the resource, you'd get a create before delete which would avoid this
a
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.
b
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
a
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.
g
a
Nope.
I want "keep on replace" basically.
Or to be very very specific: "orphan on replace"
l
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...
💪🏻 1
m
This is an interesting idea. @billowy-army-68599 could you open an issue in pulumi/pulumi with a summary of this thread?
f
❤️ 2
m
Thanks!
a
FWIW I think cloudformation calls this "DeletionPolicy: Retain"
👍 1
5 Views
Open in Slack
PreviousNext
Powered by

Pulumi Community

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.

Powered by