https://pulumi.com logo
Join Slack
Powered by
Hi guys! Is it possible to do "update before delet...
# general
b
Hi guys! Is it possible to do "update before delete"? For instance, I have a GCP Https proxy target, which depends on a certificate and I cannot replace a certificate cause another resource depends on it.
Copy code
Error reading SslCertificate: googleapi: Error 400: The ssl_certificate resource 'projects/some-project/global/sslCertificates/base-site-ssl-certificate' is already being used by 'projects/some-project/global/targetHttpsProxies/base-site-http-proxy', resourceInUseByAnotherResource
l
That should work normally. Can you post a code snippet for the certificate and proxy? I suspect you lock the naming of the certificate and not let Pulumi do its autonaming. See the last paragraph here: https://www.pulumi.com/blog/infrastructure-as-code-resource-naming/#logical-vs-physical-names
b
@limited-rainbow-51650 it has nothing to do with naming. I generate self-signed certificate each time, therefore .certificate and .private_key properties of the ssl_certificate object change. Since target https proxy depends on it, I cannot do a "replace" operation on the ssl_certificate.
In terraform you can replace it using "update before delete" or "create before delete", smth like that, I do not remember exactly, but I think those two are separate
there is no mention of how to use it
s
@better-actor-92669 You need to create the new `SSLCertificate` before deleting the existing one (here: 
base-site-ssl-certificate
). I.e. the new one needs another name because the old name is already used. Therefore simply adding a small, unique hash would solve it. That’s what Ringo means.
@better-actor-92669 The 
deleteBeforeReplace
field is in the 
ResourceOptions
(e.g. in NodeJS).
l
Right, and adding that hash is something Pulumi does by default if you don’t provide a value for the 
name
property of your certificate resource. On the other hand, if you want 
delete before create
like mentioned in issue 450 referenced above, set the 
deleteBeforeReplace
property.
b
@stocky-island-3676 thank you. It will for sure solve the issue, i do it for postgresql instances, since google reserves a name for a long time after deletion. However, it doesn’t answer my initial question about the resource lifecycle. Imagine that you have a cerificate, let’s say as a secret, and when you change it , you don’t want to replace the name of the resource
l
@better-actor-92669 that is again a reason to let Pulumi do its autonaming.
b
@limited-rainbow-51650 , @stocky-island-3676 thank you. I will take a look at that property. Strange that I haven’t found it in the programming model article
s
l
b
@limited-rainbow-51650, I was talking about deletebeforereplace. Autonaming makes sense, thank you for the explanation, however I try to specify resource name to have some consistency in gcp console.
l
@better-actor-92669 which means you are overriding the autonaming. Autonaming is the biggest reason for not ending up in the situation you are in now.
b
Yeah, I agree. But if I want to avoid autonaming, let’s say for the consistency of ci cd, I can’t afford to have random names each time. In some cases I need to have control over the resource lifecycle
That’s why that deletebeforecreate exists I guess
l
The naming is not fully random. If you create e.g. 
pulumi.gcp.SSLCertificate('my-name-here', …)
, when applying, the resource on GCP will end with 
my-name-here-<hash>
so you should still be able to identify it.
In the end, it is still your call, but definitely have another look at the autonaming and see if you aren’t taking a lot of hassle upon yourselves by bypassing it. I haven’t had any problems so far with it.
As a closing note: before Pulumi, I used Terraform. In Terraform, I had to manage the naming fully myself, meaning I needed the hassle to make the resource name unique myself. In Terraform, they needed the reverse lifecycle trick as a result: 
create_before_destroy
https://www.terraform.io/docs/configuration/resources.html#create_before_destroy I’m glad that Pulumi improved on this with the autonaming.
👍 1
s
@better-actor-92669 For CI/CD consistency, Pulumi uses stacks where the state is saved (similar or same(?) like Terraform). That way a repeated application (
update
) let’s say of the 
SSLCertificate
wouldn’t change sth. I.e. it’s idempotent. (If that’s not the case, it’s definitely a bug.) I’ve linked the “Progamming Model” documentation in the Github issues.
b
Sorry, I think I confused you. I don't really want to change the 
resource_name
name, which is the first argument, I only care about the 
name
s
I only care about the 
name
That’s what we’re also talking about. Pulumi automatically sets the 
name = resource-name-hash-suffix
if you didn’t set the 
name
for yourself. That’s the new, good thing compared to Terraform which doesn’t do this, AFAIK.
👍🏼 1
b
Got you, thanks!
@stocky-island-3676, when I mentioned the CI-CD part, I didn't mean pulumi specifically. Let's say you create your whole infrastructure automatically using any CI/CD tool or a script (very bad idea). Then, you want to access a resource via it's name in latter steps (outside of pulumi). For instance, to do host configuration via Ansible or apply a salt state. In this case, you want some consistency of how you assign your Cloud DNS names using the pattern 
some-nginx
+ 
pulumi.get_peoject()
. I hope you understand me now.
and yes, both autonaming and deletebeforereplace work like a charm. Thank you guys!
s
@better-actor-92669 Right, I know this problem, too. Still, in the 
SSLCertificate
case here, you basically have these options (or do I miss sth.): 1. Create the new certificate beforehand with a new name (with whatever suffix or prefix). 2. Delete the old certificate first => downtime, then create the new certificate with the same name. 3. 1.) with 
name = B
& use 
B
. Then (sometime later probably if everything works out) 2.) with 
A
, & re-use name 
A
(with new values).
b
yeah, @stocky-island-3676, thanks a lot. For now, I just used autonaming. Cheers!
Open in Slack
PreviousNext
Powered by