This message was deleted.

sparse-intern-71089

10/03/2023, 9:49 PM

This message was deleted.

little-cartoon-10569

10/03/2023, 9:50 PM

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

10/03/2023, 10:27 PM

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.

😢 1

sad panda 1

calm-cat-43230

10/04/2023, 1:05 AM

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

calm-cat-43230

10/04/2023, 1:06 AM

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

little-cartoon-10569

10/04/2023, 1:08 AM

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

10/04/2023, 1:19 AM

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.

🙌 1

little-cartoon-10569

10/04/2023, 1:20 AM

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

🙂 1

fierce-ability-58936

10/04/2023, 1:20 AM

Wait, so why don't you just give it an alias with the old name? https://www.pulumi.com/docs/concepts/options/aliases/

🙌 2

little-cartoon-10569

10/04/2023, 1:21 AM

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

little-cartoon-10569

10/04/2023, 1:21 AM

I shall repeat the experiment with this improvement.

little-cartoon-10569

10/04/2023, 1:30 AM

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

🆒 1

great-sunset-355

10/07/2023, 10:58 AM

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

10/07/2023, 8:06 PM

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

10/08/2023, 9:01 PM

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

little-cartoon-10569

10/08/2023, 9:06 PM

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

35 Views

Open in Slack

Previous Next

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.