Question about the practicalities when refactoring Route53 r

Question

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

little-cartoon-10569 · Answer

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

little-cartoon-10569 · Answer

First experiment completed Re this gt 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

calm-cat-43230 · Answer

thanks for sharing this there are similar stories across various AWS resources always good to hear about them

calm-cat-43230 · Answer

Would the `allowOverwrite` input similar to `deleteExisting` in be helpful here

little-cartoon-10569 · Answer

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

little-cartoon-10569 · Answer

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

little-cartoon-10569 · Answer

Thanks for pointing out that property I didn t know about it before

fierce-ability-58936 · Answer

Wait so why don t you just give it an alias with the old name <https www pulumi com docs concepts options aliases >

little-cartoon-10569 · Answer

You know working under pressure to fix a problem I made does not suit me I miss all the obvious solutions

little-cartoon-10569 · Answer

I shall repeat the experiment with this improvement

little-cartoon-10569 · Answer

Hmm Seems like this is so correct I don t even need the allowOverwrite

great-sunset-355 · Answer

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

little-cartoon-10569 · Answer

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

fierce-ability-58936 · Answer

I sometimes have aliases in transformations so they re are all in one place and can be removed easily

little-cartoon-10569 · Answer

Not a bad idea Easier to manage the feature flagging this way too