Question about the practicalities when refactoring...
# aws
l
Question about the practicalities when refactoring Route53 records: • I have changed the Pulumi (state) name of a Route53 record. This will cause a delete / recreate in AWS. • The deleteBeforeReplace option isn't relevant, because Pulumi doesn't consider this a replace: it's a whole new resource. • A simple
pulumi up
will fail, because the new record will be created before the old one is destroyed, and AWS will cause that to fail. What is the correct / easiest solution? • I'm hoping that renaming the base record in AWS will be enough: this will prevent the name clash, allowing the new record to be created. However, will it delete the correct record next? Or will it delete based on record name, which means the new record will be deleted? • Also, when I browse in Route53, there are a pile of related records that presumably have been created by AWS behind the scenes: TXT records with
_amazonses
prefixed; CNAME records with guids prefixed, and CNAME records with guids and
_domainkey
prefixes. Will these ones cause a clash and a failure?
I'm going to create a new project to test this, but I'm time constrained, so any answers that get here faster than my investigations would be gratefully received!
First experiment completed. Re: this:
I'm hoping that renaming the base record in AWS will be enough: this will prevent the name clash, allowing the new record to be created. However, will it delete the correct record next? Or will it delete based on record name, which means the new record will be deleted?
It does delete the new record. Editing the record is not a solution.
c
(thanks for sharing this — there are similar stories across various AWS resources, always good to hear about them)
Would the
allowOverwrite
input (similar to
deleteExisting
in CDK construct) be helpful here? https://www.pulumi.com/registry/packages/aws/api-docs/route53/record/#inputs
l
Ooo. It might. It would probably have to be set before the change.. but my experiment config is still in place, it's easy to test.
Experiment done. It has exactly the same result as editing the record, without having to make a manual change. Which is a bit better, but still not ideal. To solve my current problem, this does open up a couple of shorter workarounds, and I like this one: 1. Add the allowOverwrite property and run
pulumi up
. This results in the record being created (which means updated) then deleted. 2.
pulumi state delete
the new resource. 3. Remove the allowOverwrite property and run
pulumi up
, to get everything where I want it. Steps one and two can be reversed with no difference to the end result.
Thanks for pointing out that property, I didn't know about it before!
f
Wait, so why don't you just give it an alias with the old name? https://www.pulumi.com/docs/concepts/options/aliases/
l
You know, working under pressure to fix a problem I made does not suit me. I miss all the obvious solutions...
I shall repeat the experiment with this improvement.
Hmm. Seems like this is so correct, I don't even need the allowOverwrite...
g
Aliases are a good solution but unfortunately, they will often pollute the codebase, especially if you have nested components, etc... you'll need to pass aliases via resource options all the way down making the code more convoluted (sometimes) So for some solutions I prefer the state surgery
l
I put them directly where they're needed. That would become a problem only if the affection component resources were to be called in new places, after adding the aliases. And that doesn't apply in this case. Also, I prefer to wrap them in feature flags and remove them as soon as all affected stacks have been deployed. Once everything has been renamed successfully, the old aliases can be usually safely removed.
f
I sometimes have aliases in transformations, so they're are all in one place and can be removed easily.
l
Not a bad idea. Easier to manage the feature-flagging this way too.