Add pulumi stack rename to allow you to rename a stack

[ellismg]

Now that we no longer require stack names to be unique across an organization it's natural to want to rename and existing stack you've created, since we previously recommended to use <project-name>-<unique-identifier> as a stack name, e.g (my-great-project-dev).

Today, renaming a stack is not a straightforward process. In addition to backend specific changes, the stack's name is also part of the URN of every resource we've created for a stack, so simply changing the name would cause the engine to believe that it needs to replace every resource.

We should add a pulumi stack rename command which should handle both backend specific logic to do the rename (e.g. in the service, updating some metadata about a stack name) and handle the updates needed to the existing checkpoint file such that URNs now have the new stack name.

[chrsmith]

Just as an FYI, I do not think we can 100% guarantee the operation is safe. So we want to add a warning by default, such as when trying to delete a stack that still has resources. (And --yes or --force to bypass automatically.)

Doing a find/replace across resource URNs will cover the majority of cases. But because you can get the stack's name at runtime via pulumi.getStack, it's possible to have the stack's name bleed into resource properties too. (And applying the same find/replace could lead to false-positives for a generic stack name.)

In practice I don't think this is going to be a problem, but I can imagine situations where renaming a stack could lead to trouble.

Alternatively, we may want to have the rename as a special kind of update. Where the command first previews the changes that would take place if the rename were to be made. That would allow you to see if there were any unexpected or problematic infrastructure changes, before proceeding.

[lukehoban]

But because you can get the stack's name at runtime via pulumi.getStack, it's possible to have the stack's name bleed into resource properties too.

Actually the common case is even worse - pulumi.getStack() is frequently used as part of how the "name" of resources is generated, which means every resource would change identity and get recreated on the next update.

Alternatively, we may want to have the rename as a special kind of update.

This is an interesting idea...

[ellismg]

Just as an FYI, I do not think we can 100% guarantee the operation is safe. So we want to add a warning by default, such as when trying to delete a stack that still has resources. (And --yes or --force to bypass automatically.)

I understand what you are saying here, but I wanted to point out that a rename operation by itself can be 100% safe, assuming that we just operate on the checkpoint file.

Now, it's true that if you the output of pulumi.getStack() as part of naming your resources, it's possible that the /next/ update after doing a rename would show "unexpected" changes as resources who's names depended on the output of pulumi.getStack() to name their resources now have new names, but if this was something you really didn't want to have happen, you could always rename the stack back to the old name.

Note we already have a version of this problem for any external observable state from update to update. For example, if you happened to use the value of a configuration variable to name a resource, then using pulumi config set could be considered a "dangerous" operation.

Alternatively, we may want to have the rename as a special kind of update.

@lukehoban and I were talking about this in person. I am not sure if it is a special kind of operation, but I could imagine value in pulumi stack rename showing you the output of a pulumi preview (with the engine configured to use the new stack name and the checkpoint it uses as the input state to have rewritten URNs) so you could see how such an change could impact a future update.

[lukehoban]

Fixed with #2561.

[4c74356b41]

wait-wait, so I can create stacks with the same name. how does that work? how would i differentiate between those?

[lukehoban]

wait-wait, so I can create stacks with the same name. how does that work? how would i differentiate between those?

You cannot create two stacks with the same fully qualified name. You can have two stacks named, e.g. dev, in different projects and/or organizations.

What specific comment here led you to think there was a potential concern here?

[4c74356b41]

i was just wondering how it works, thats it ;)