Ability to name resources and sane default names

[perpil]

Summary

Make names of cloud resources human friendly

Feature Spec

This isn't really a spec, more of a placeholder to start the discussion. The names of the resources wing creates in the cloud are auto-generated and not human friendly. Furthermore, there doesn't seem to be a property that allows them to be set by the developer (I looked through the doc, but didn't see a name field). I'd like at the minimum to be able to specify resource names so I'm not looking in buckets like: terraform-20221125051333963700000005. Ideally there would be some automatic naming too that is more grok-able than a uuid. I'm not sure whether you need a high level entity like a project to help with this, but maybe account-region-project-stage-name.

Use Cases

Allow humans to interact with the resources and be able to programmatically generate resource names to integrate with outside tools instead of needing a mapping file.

Implementation Notes

No response

Component

No response

[Chriscbr]

Love this idea @perpil! 🙌

It would be really helpful to have a general naming utility for resources, since the naming constraints on different clouds can vary. @eladb previously suggested an API that allows name generation to be customized with different options... here's a sketch:

export class NameGenerator {
  // register a name generator for a specific scope
  // normally this will be called at the root
  public static register(scope: Construct, gen: INameGenerator) {...}

  // returns the name generator associated with the current scope
  public static of(scope: Construct): INameGenerator {..}
}

export interface INameGenerator {
  // default naming scheme
  make(resource: Construct, opts?: Options): string;

  // DNS-compatible naming (opts can be used to customize)
  makeDns(resource: Construct, opts?: Options): string;

  makeAzure(r: Construct, o?: Options): string;
  makeGcp(r: Construct, o?: Options): string;

  // ...
}

// 
export interface Options {
  readonly minLen?: number;
  readonly maxLen?: number;
  readonly lowercase?: boolean;
  readonly uppercase?: boolean;
  readonly dots?: boolean;
  readonly hyphens?: boolean;
  readonly nonalpha?: boolean;
  // ...

// usage 
const bucketName = NameGenerator.of(this).makeDns(this);

Maybe this could fit somewhere in the core of the SDK?

In cases where we can't control resource names, we could also try and fall back to tagging on AWS for example.

[ekeren]

Nice, this configuration will be target specific, right?

[Chriscbr]

Yes, I think each cloud may be able to create its own name generator (or multiple if different ones are needed for different circumstances), just by defining a new class that implements one or two methods, and that would be used across all resources in a users app.

[skyrpex]

Digging a bit into details here. The CDK uses ID and Path like this:

root/ # (ID=root, PATH=root)
    cloud.Bucket # (ID=cloud.Bucket, PATH=root/cloud.Bucket)
    cloud.Queue # (ID=cloud.Queue, PATH=root/cloud.Queue)
    cloud.Queue-OnMessage-bd2fcb591d7f8d4d/ # (ID=cloud.Queue-OnMessage-bd2fcb591d7f8d4d, PATH=root/cloud.Queue-OnMessage-bd2fcb591d7f8d4d)
        Code # (ID=Code, PATH=root/cloud.Queue-OnMessage-bd2fcb591d7f8d4d/Code)

Now, imagine an app with tens of functions, along with tens of resources with ID Code. Maybe we don't need tens of functions to see the point, let's use three:

root/ # (ID=root, PATH=root)
    cloud.Bucket # (ID=cloud.Bucket, PATH=root/cloud.Bucket)
    cloud.Queue # (ID=cloud.Queue, PATH=root/cloud.Queue)
    cloud.Queue-OnMessage-bd2fcb591d7f8d4d/ # (ID=cloud.Queue-OnMessage-bd2fcb591d7f8d4d, PATH=root/cloud.Queue-OnMessage-bd2fcb591d7f8d4d)
        Code # (ID=Code, PATH=root/cloud.Queue-OnMessage-bd2fcb591d7f8d4d/Code)
    AnotherQueue1 # (ID=AnotherQueue1, PATH=root/cloud.Queue)
    AnotherQueue1-OnMessage-5d334a6dc589a1bf/ # (ID=AnotherQueue1-OnMessage-5d334a6dc589a1bf, PATH=root/AnotherQueue1-OnMessage-5d334a6dc589a1bf)
        Code # (ID=Code, PATH=root/AnotherQueue1-OnMessage-5d334a6dc589a1bf/Code)
    AnotherQueue2 # (ID=AnotherQueue2, PATH=root/cloud.Queue)
    AnotherQueue2-OnMessage-f812794000c38841/ # (ID=AnotherQueue2-OnMessage-f812794000c38841, PATH=root/AnotherQueue2-OnMessage-f812794000c38841)
        Code # (ID=Code, PATH=root/AnotherQueue2-OnMessage-f812794000c38841/Code)

The Code ID doesn't have any meaning outside of the whole hierarchical context, and the Path is too long to be useful for humans. We could handle names in a different way, though!

What if we use the following naming convention:

• Name (Code, which is the CDK ID). Useful when you know the parent
• Path (same as the CDK Path)
• ID (which would be $name#$shortHashOfPath, for example Code#5d334a).

This ID is now meaningful enough to know which resource it represents, and also is distinguishable from any other resource which shares the same name. Also, the meaning of the names are proper now: name is not unique, and ID is indeed unique.

[eladb]

@skyrpex you are talking about resource logical identifiers (within the Wing app) and I believe @perpil is talking about the physical names of the resources once they are deployed into the cloud provider.

Related, but not exactly the same thing. Perhaps we should create a separate discussion to discuss logical identities?

[perpil]

Correct, I'm talking about the physical identifiers. I'd like to be able to deploy a Wing app into my account, potentially multiple times and have the resources named things that I can easily understand in the console. Bonus points if there are no uuids/hash in the name. It's one thing to deploy it, but this feature is for actually operating it without accidents because you were looking at the wrong thing.

[ekeren]

Hey @perpil, going back to the use case:

Allow humans to interact with the resources and be able to programmatically generate resource names to integrate with outside tools instead of needing a mapping file.

I was wondering about the role of aws tags in respect to this use case?

For example, in the case of a lambda function that is part of a wing app named image-extractor and part of a Resource named image-store the compiler can provide default (configurable) tags, as follows:

Key	Value	Comment
Name	wing:image-extractor:image-store:function	unique namespace:name
app	wing:image-extractor	web application name
namespace	wing:image-extractor:image-store	unique namespace
wing-type	cloud.Function	the type of the resource
env	prod	environment inferred from compilation

[perpil]

I think tags would be nice, but to date are fairly invisible to the console/cli. They help you with use cases like billing and IAM permissions and could help with discovery for tooling, but still aren't visible enough for humans poking around. What I'd like is to be able to go directly to the service and immediately understand things vs. starting here.

[perpil]

Adding a note here that you can see the impact of generated names in the GSG. Instead of saying go to the queue hello-queue and bucket wing-hello-<account>, you must provide generic instructions.

[eladb]

Yes, I think this is a pretty lousy experience at the moment.

Moved this to an issue (bug) #1047

[ekeren]

@perpil , I've noticed @marciocadev is working on #1078

I suggest you take a peek on the pull request

[perpil]

I think Elad was quoting marciocadev and that made it look like he talked to me, I've only slacked with marciocadev. For a core piece like this, wingdevs should define the RFC and behavior so it's consistent with the rest of the sdk and paradigms. My thoughts are below:

1. Is it a resource specific thing or under ResourceProps

If you plan on adding resources that are named based on their parent (i.e. a dynamo stream), it should be up a level from ResourceProps. Terrible naming here, but if you want to defer creating an interface like NamedResourceProps to define whether there is a name property or not, one solution is to add the name property to the resource specific properties and push it down later.

2. If the resource is part of a composite resource, it would be impossible to define two instances of the composite resource because the physical name will conflict, so we really don't want to encourage this.

I'm not sure I follow, as long as each resource has a different id or name and the physical name of the composite resource is generated from that, what is the issue? The developer can set two different ids or names.

3. If this is needed for human readability, it might be better to assign resource tags based on the display api we are working on.

Is this what you are describing here? Because physical names will always be more useful in the human and tooling context.

4. There might be very different behaviors across providers when it comes to physical names.

True, it could be one provider allows you to set a physical name and one doesn't. Could that be validated and enforced when you build the target?

[Chriscbr]

Hoping to provide some clarity here -- I'm not sure if I'm on the same page, so I'll try and explain how I understand things. But I think regarding (2), what Elad may be referring to is that, suppose we design our APIs to operate similar to this:

resource B {
  init({ name: str }) {
    let physical_resource_name = name;
    // create an AWS Lambda function with `physical_resource_name` as its name
  }
}

resource A {
  init() {
    new B({ name: "hello" });
    new B({ name: "world" });
  }
}

Then the following code would have fail if we tried compiling and deploying it to the cloud:

new A() as "instance1";
new A() as "instance2";

The error would happen while running terraform apply because even though each copy of A has a different name, we still end up with two AWS Lambda function named "hello" and two AWS lambda functions named "world". In general, this problem is what construct IDs solve pretty well -- because by concatenating the IDs at each level of the tree, we can get full path names like:

instance1/hello
instance1/world
instance2/hello
instance2/world

Every resource path is guaranteed to be unique (in your app), since tree siblings are not allowed to have the same construct ID.

Based on this, I think our problem is basically a question of how to transform these paths like instance1/hello into something human-readable based on each cloud provider/resource provider's particular requirements, while still maintaining the property that every resource name is unique within your app. For example, we can remove characters that aren't allowed in the physical resource name of a particular resource, but then sibling resources could end up with the same name -- to avoid this, we usually append a hash to the end of the name.

I've written some more about this here - curious to hear your thoughts: https://github.com/winglang/wing/blob/main/rfcs/resource-naming.md

[perpil]

Do you mean this? The link above doesn't work.

My understanding is name is an optional field set by the developer, so if it is set at all, it is up to the developer to make it unique. If name isn't set, the SDK generates a unique name. The wing SDK shouldn't set the name property on a child unless the parent has a name property. If A has a name, and wants to propagate the name to B, it should do it something like this: new B({ name: "${name}-hello" }); or whatever your syntax is for interpolating strings so it is a combination of A's name and hello.

[Chriscbr]

Oops - yes that's the correct link.



You're right, we can also solve this by letting each parent concatenate the names explicitly. I guess the idea I'd put forward is that I think there's some utility to be able to handle that logic automatically, and/or let developers specify how they want those concatenations to happen across entire subtrees of resources. For example, "for all of these GCP resources I have grouped together, I want the names to be joined with a dash and trimmed to 64 characters" while for AWS it might be different or less stringent etc. But otherwise, what you've described is basically the essence of CDK constructs.

Also -- it could be nice to let people customize these "default unique names" generated in Wing. (For example, new cloud.Bucket() is created with a default id of cloud.Cloud, but it makes sense to give users knobs/options for this.)

[perpil]

I think we're on the same page. So to get automatic naming based on id, you can either:

1. Set the id and wing will use it as a prefix
2. Don't set an id and wing will use the default id as a prefix

Appending hashes is ok with id or default id based naming.

For custom naming, the developer sets the name property and wing uses it verbatim. In the case of composite resources where naming isn't exposed, wing uses the name property in generating the name. On composite resources, with a named parent, I don't think there should be any hash or uniqueness appended. Those should have a name based on the parent name and composite resource type like ${parentname}-ddbstream. If name is used, it's up to the developer to make it unique across projects/accounts etc.

I think this should cover the main use cases:

1. Generate a unique name for me
2. Generate a unique name prefixed by id
3. Use my name