anyone have success in using the `aliases` feature...
# typescript
e
anyone have success in using the
aliases
feature to move a resource from one child library to another?
l
Library? Aliases allow effective repositioning within state. It's not related to libraries, modules, classes or similar.
Yes, I've used
aliases
to move resource within state. It's an effective remediation for planning-after-the-fact 🙂
Which I do all too often...
e
yes in state, but referencing imported libraries is what I mean
trying to change the parent of an s3 bucket. Work is done in a separate library that I’m linking locally
I tried referencing by urn directly, parent, name, and nothing
l
Importing from libraries doesn't overlap the problem domain that aliases solve, as far as I can tell?
If the resource isn't moving between state files, you don't need to any import-related stuff. And if it's not moving within the state's hierarchy of resources, you don't need to do any aliasing.
You can move the code into a new location in your code, including to new libraries, and if the resource remains in the same place in the state (i.e. same parent resource) then you don't need to do anything.
e
removing any library from conversation, a simplified attempt..
Copy code
{
		aliases: [{
			name: `${config.autoscalingConfig.autoscalingGroupConfig.name}-codedeploy-bucket`
		}]
	}
that’s the change I made to an existing bucket
previously it was
{ parent: codeDeploy }
my goal is to just to remove the parent. pulumi wants to destroy and create the bucket
so I’m clearly not using the aliases correctly
l
Ah. So what you need is to find the old URN (under codeDeploy), which you can do by searching the output of
pulumi stack --show-urns
e
I shouldn’t have to use the urn, though
and I tried the urn previously with no luck
I might be on to something here…adding the old name AND old parent, might work
l
Yes, you don't need to, it's just a habit I use to ensure I get the right name (since I have often renamed a resource at the same time as moving it.. which I probably shouldn't).
Yes, the more info you put into the alias description, the better. The docs explain what the properties are for: https://www.pulumi.com/docs/reference/pkg/nodejs/pulumi/pulumi/#Alias
The name in the alias is obviously the old name, not the current / new name.
I have got that wrong in the past.
And that's where --show-urns is helpful.
e
yea, I can’t really use the URN outside of troubleshooting because that’s where the library comes in. It’s used in multiple projects, so the dependent repo’s will have different S3 Bucket URNS
l
If you're moving the code into a library, and therefore the code will now be used when creating multiple resources (where before it was creating one), then I think aliasing isn't appropriate?
You might be better off importing... it's a messy solution requiring at least 2 calls to
pulumi up
, but it should get your state in better shape.
e
so I ended up figuring it out by specifying the name and the parent urn, needing both of those
thanks for the help!
luckily the urn name is consistent, so I just manipulated that to work with proper string interpolation so it’s universal
👍 1