-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename a resource #458
Comments
I was actually dreaming about this last night. (No joke.) It seems to me there are two approaches to go about this: (1) rename the state in the checkpoint file, or (2) apply renames "during" the The first seems simpler, but it doesn't fit the workflow I anticipate wanting to use when running into this issue. Namely, you've renamed something in your program and want to match the old state with the new state during an update. Being able to preview that to make sure you got it all correct and then locking it in alongside the update seems to fit our model so much better than an approach that mutates the checkpoint file's URNs prior to actually applying the update in which the rest of the updates are going to take place. The update should be the one atomic advancement of the state. How might this look? I'm thinking you could just have an option to both We also need to think about component authors making breaking changes to renames and wanting to minimize the impact of said updates. As an extreme example, imagine we rename some components deep in the bowel's of our own cloud framework. To minimize the customer impact, we could redistribute a remapping file that does the bulk renames of any resources being ingested. In theory, we could even have some story for autodetecting during upgrades, based on semver. |
That seems reasonable - but not clear why it's much better than separately
I do worry a lot about this. It feels like just about any change in one of our components will need to be a semver breaking change in the way we are currently approaching things. If we can come up with some reliable way to annotate components with renames they should apply - that could be very helpful (though not yet clear what the impact of implicitly forcing renames on a users checkpoint file will be). |
How about adding
This approach means that the rename has a trail in source control where both names exist at once. As a bonus, code that still uses the old name wouldn't immediately break, but could issue a warning about using a deprecated / non-primary resource name. |
I really love this idea. It also points out a critical flaw in everything discussed earlier, which is that it would not be tracked in source control, and instead would have been a trail of manually run commands. |
Thanks @brandonbloom! In fact, @pat @ellismg and myself were discussing almost exactly the same thing just yesterday (though I was calling it In our discussion yesterday we were very optimistic that this would work. Also notable that this additional annotation only needs to stay around in source code as long as you have stacks in the wild that use the old names that you might want to be able to migrate forward. Once you know no more of these exist, you can remove it safely. |
I've opened an initial PR for investigation at #2404. Here's a quick note on the general approach: Aliases provide a way for a resource to be reliably renamed without forcing recreation of the underlying cloud resource. This is important for several scenarios:
The idea of Users can add For the simple end user case, a resource can change from this: const res = new Resource("foobar"); to this: const stackName = pulumi.getStack();
const projectName = pulumi.getProject();
const res = new Resource("baz", { aliases: [`urn:pulumi:${stackName}::${projectName}::my:module:Type::foobar`]}); The complexity of building up the old URN is unfortunate here - but it is in general important to be able to express all the possible changes that might be needed to the URN. We could consider adding shorthands for some common cases, but even better would be to use this feature to simplify the URN scheme itself, so that this is not as difficult. For components, there are two scenarios:
For the first case, we will want this to cause all children to be implicitly aliased using the parents alias root. This is not implemented yet in the PR, but should be possible. For the second case, the component can use an alias internally constructed based on the refactoring in question (again, a little complicated with current URN scheme, but possible). The third case is unfortunately not clear yet. If the component is only used in one place (like during initial implementation) the implementation can be updated to alias to the old child identity (and the child resource can be removed). In practice, this will handle the common cases of initial refactoring into components. But in more complex scenarios users may want to adopt a resource into a component which was defined elsewhere and manages a few resources in a addition to the one being adopted. It's hard to imagine fully general patterns for supporting this, but if important, it could be that component resources get an additional flag for something like |
I do wonder if it would be possible to have some way to mark "I'd like you to add an alias to me that is based on the URN that would have been assigned if I was not part of a component hierarchy, and instead had been defined at top level". I think that would provide a nice gesture for taking an existing resource and adopting it into a component hierarchy and possibility could be done in a way such that I didn't have to try to build a URN myself. |
We reviewed the design proposal in #458 (comment) and #2404, and there was consensus to move ahead with this approach. The biggest concern was with the ability to "rename" a component and have that alias down through children - this is currently difficult because of the (effectively required, but also for many cases practical) pattern of including the
This breaks the child aliasing scheme because not just the parent type needs to be updated, but also the child resource name - but we don't know a-priori how to inject the "old name" into the name used for the child resource. The solution we landed on for this was to automatically replace the new parent resource name in the prefix of the child name with the old name as part of constructing the child aliases. This is a little bit more "convention"-based than we'd ideally like, but practically will work well and will encourage additional consistency. We will add this to component design guidelines. We also discussed helpers for URN construction. We will likely add one of these to construct a URN from a parent and child Resource object (which can be done synchronously even though the |
@lukehoban I know this is an old issue, but the aliases are not fun to use when you create nested components and I would really enjoy having a rename CLI |
Also #837 was closed as a dupe of this. But after the actual implementation changing the parent-child relationship is still a braking change, despite if being purely cosmetic/organizational for pulumi, having to delete and create a new resource in order to change, or create this organization (parent-child) marked it prohibitive for various cases. |
As noted as well in #837 (comment), aliases make it possible to change the parent of a resource without replacement, but you must indicate the previous parent name as an |
I was trying to rename an |
@slavafomin I'd suggest opening a new issue for that. If you could add what language SDK and what the alias looked like to that ticket it will be much easier for us to work out what could have gone wrong and help fix. |
Today, if you rename a resource in code, Pulumi has no idea that the old name and new name are related. It schedules a delete of the old and a create of the new.
A workaround is to manually edit the checkpoint file to change the name in the same way - since these names are just logical names that are only tracked in the checkpoint file, this is technicaly possible.
It might be nice to have a command line way to do this more safely (especially for cases where the checkpoint file is managed remotely).
This is similar to
terraform state mv
. Generally, we will likely eventually want logical equivalents of allterraform state
commands.The text was updated successfully, but these errors were encountered: