🆕 Overriding IDs

[jamie-lynch]

Each Cloudformation resource must have a logical id. When these ids change, the resource will be deleted and a new one created with the new logical id. This change can cause some issues where resource is referred to elsewhere by its logical id (or something dependent on the id) for example, security groups in other stacks or dns entries.

Resources defined in CDK are given a unique id. This is a concatenation of the construct id provided and a generated 8-digit hash. This unique id is also used as the logical id.

When migrating existing stacks to CDK, this means that the logical IDs will all be changed, causing the problems described above. To negate that many of the constructors defined in this library implement some logic to override the id, setting it as only the construct id, allowing the stack to be migrated without the resources being re-created. For example:

export abstract class GuPolicy extends Policy {
  protected constructor(scope: GuStack, id: string, props: GuPolicyProps) {
    super(scope, id, props);

    if (props.overrideId) {
      const child = this.node.defaultChild as CfnPolicy;
      child.overrideLogicalId(id);
    }
  }
}

While this practice has proved convenient for migration, is it something that should be implemented everywhere, in select places, or not at all?

[jacobwinch]

While this practice has proved convenient for migration, is it something that should be implemented everywhere, in select places, or not at all?

Unfortunately it doesn’t seem like we can avoid using these overrides for stack migrations, but perhaps we can hide some of this complexity from our users.

One option to consider would be adding a migratedStack (or similarly named) boolean to GuStack (perhaps defaulting to false). We could set this to true when we create the boilerplate for a stack migration via cdk-cli.

This would allow us to check whether we need to override the logical id within each constructor, without relying on users passing in an extra prop for all existing resources or understanding the reasons behind this overriding behaviour.

[jamie-lynch]

One option to consider would be adding a migratedStack (or similarly named) boolean to GuStack (perhaps defaulting to false). We could set this to true when we create the boilerplate for a stack migration via cdk-cli.

That's a great idea!