What are the best practices when it comes to naming resources inside a component resource? I am trying to understand whether it's an anti-pattern to use the resource name of the parent as part of the resource name of its children (I don't mean the actual name of the resource, I mean the one that refers to the resource inside the stack). Reason I ask is that doing so seems to make renaming component resources absurdly difficult, but not doing so seems to not allow a user to create two of the same component inside the same stack due to name clashes

I generally try to use

name

only. I definitely don't like adding the resource type into the name (though it seems to be hugely popular.. no idea why). The only time I change the name of a child from that of the parent is when there's more than one child of that type.

Maybe I haven't described the problem properly. Imagine I have a component resource like this (using Python because that's what I'm using to author the components):

class EC2SecurityGroup(pulumi.ComponentResource):
    """AWS EC2 Security Group."""

    security_group_id: Output[str]
    """The ID of the security group."""
    vpc_id: Output[str]
    """The VPC ID the security group is in."""

    def __init__(
        self,
        resource_id: str,
        args: EC2SecurityGroupArgs,
        opts: pulumi.ResourceOptions | None = None,
    ) -> None:
        """AWS EC2 Security Group."""
        super().__init__("my:custom:SecurityGroup", resource_id, None, opts=opts)
        security_group = pulumi_aws.ec2.SecurityGroup(
            "security-group",
            group_name=args.name,
            group_name_prefix=args.name_prefix,
            description=args.description,
            tags=args.tags,
            vpc_id=args.vpc_id,
            opts=opts.merge(pulumi.ResourceOptions(parent=self)),
        )

If I use a static name for the security group to be something like

"security-group"

and not

name

, then if I create two instances of the component I get a name clash on the child security group resource. However, if I use some dynamic name like

name

, then when you pass

aliases=[pulumi.Alias(name="old-name")]

to the ResourceOptions object of the parent, that takes effect only on the parent and not on the security group child resource underneath

That is correct. Pass

name

to all the children. This will handle 90% of cases

Hmmm, seems like this gets super complicated if you try to use the component resources remotely: https://github.com/pulumi/pulumi/issues/18801

That doesn't seem related. That's about getting a component resource to not delete if you rename it and try to use aliases to ensure that Pulumi doesn't delete it.

It says that they drop aliases when using component resources over RPC, does it not?

Only for the component resource. Not for the real resource within.

The options are coming from the parent and then merged with a parent option, so they would also affect the children

The aliases are provided to all children when I write my code. I think it's that way in the examples too?

It's uncommon enough that likely surgery on the state could fix it, but I'm also not going to be the person actually wanting to do the renaming most of the time

I didn't need surgery in state. I updated the code to add the aliases to each of the resources, ran

pulumi up

, then remove the aliases from code.

Yeah, it's not impossible to fix, I'm just trying to make sure I'm not doing the obviously wrong thing because I'm using component resources directly for some of my stuff and then trying to expose them for multi-language use for others to use (frontend teams, etc.)

This wouldn't work for all people all the time. But we only had two stacks and didn't re-use that stuff in any other projects, so it was easy.

100%, but then some of the costs are not named upfront, so I'm just trying to make sure that I'm doing the right thing so at least if I hit a problem like this that I know it's not me doing a footgun

My rule of thumb is: if you can talk to all the consumers of the code, just use a component resource, it's easiest. If you need to share the code with people you don't (often) talk to, then one of the provider options is probably better.

My issues are more around the features that work or don't work when the component resource is triggered over RPC

Ah, the old "AWSX" conundrum. That library is actually a good example of the problems that widely-used component resources can bring 🙂

@delightful-queen-14969 The short answer (I think?) to your original question: The component's name should be templated in the child resource names, e.g.

${name}-cluster

. I'll ensure that we note the specific case of renames (which I had not even considered - thank you!)

Thanks, I'm just trying to make sure that my stuff is following best practices so at least I can know I'm not swimming upstream when something isn't working. Cheers for the confirmation

Keep me posted on what your major questions are because many of my customers are also adopting components and I want to make sure the docs are as complete, accurate, and easy to use as possible.

Right now my main pain points are trying to work out whether I'm the problem or whether something just doesn't work when trying to use components in a multi language setting. I'm trying to write my stuff to keep my options open but I wouldn't have expected aliases to just be dropped, for example