Updates to support other cluster/group name formats

[rfleur01]

Background:

For legacy groups that are converted to clusters, the cluster name needs to match the ASG and the group in Teletraan. This can cause the UI to return an error because the format of the ASG is not "{env_name}-{stage_name}". It could be "{env_name} {stage_name}"

Tests:

Test all the changes made to ensure the new format is supported and there is no regression for the existing format.
New Format Cluster: helloworlddummyservice-server-rfleur
Old Format Cluster: rfleur-dev1

Show Replacement Activities

Auto Scaling Settings/Auto Scaling Configuration

Update Capacity

Click to see AMI(s) used by Hosts

Host Terminate

Cluster Config GET

Cluster Config POST

Cluster Config History

Clone Cluster

Enable Cluster Replacement

Auto Cluster Refresh View

Cluster Replacement Details

Base Image History

Cluster Refresh Status

[liyaqin1]

@rfleur01 Could you clarify the purpose of the cluster name? We already have the ASG name in rodimus, as well as the environment name and stage name in deploy. What specific role does the cluster name play? Thank you.

[rfleur01]

@liyaqin1 using the format {env name}-{stage name} causes clusters that do not follow that format to not be accessible via the UI. This update leans on the cluster_name to account for names that might not be in the {env name}-{stage name}.

[liyaqin1]

@liyaqin1 using the format {env name}-{stage name} causes clusters that do not follow that format to not be accessible via the UI. This update leans on the cluster_name to account for names that might not be in the {env name}-{stage name}.

How do we generate the cluster name?

[rfleur01]

@liyaqin1 using the format {env name}-{stage name} causes clusters that do not follow that format to not be accessible via the UI. This update leans on the cluster_name to account for names that might not be in the {env name}-{stage name}.

How do we generate the cluster name?

This does change how cluster names are generated. New clusters will still be generated in the {env name}-{stage name} format. It only adds support to get and update clusters that do not have the {env name}-{stage name}.

[liyaqin1]

@liyaqin1 using the format {env name}-{stage name} causes clusters that do not follow that format to not be accessible via the UI. This update leans on the cluster_name to account for names that might not be in the {env name}-{stage name}.

How do we generate the cluster name?

This does change how cluster names are generated. New clusters will still be generated in the {env name}-{stage name} format. It only adds support to get and update clusters that do not have the {env name}-{stage name}.

If the env/stage is lacking a cluster name generated as {env name}-{stage name}, what alternative method should be used for generating it?

[rfleur01]

@liyaqin1 using the format {env name}-{stage name} causes clusters that do not follow that format to not be accessible via the UI. This update leans on the cluster_name to account for names that might not be in the {env name}-{stage name}.

How do we generate the cluster name?

This does change how cluster names are generated. New clusters will still be generated in the {env name}-{stage name} format. It only adds support to get and update clusters that do not have the {env name}-{stage name}.

If the env/stage is lacking a cluster name generated as {env name}-{stage name}, what alternative method should be used for generating it?

This is related to the work I am doing to convert legacy groups to clusters. Many of these groups have ASGs that are not in the {env name}-{stage name} format, which prevents the UI from rendering their cluster configurations and other UI components. In short, they just wouldn't be generated via the UI. They could be generated via API OR in this case via DB insertion (via script), which is the main reason for this PR.

[liyaqin1]

@liyaqin1 using the format {env name}-{stage name} causes clusters that do not follow that format to not be accessible via the UI. This update leans on the cluster_name to account for names that might not be in the {env name}-{stage name}.

How do we generate the cluster name?

This does change how cluster names are generated. New clusters will still be generated in the {env name}-{stage name} format. It only adds support to get and update clusters that do not have the {env name}-{stage name}.

If the env/stage is lacking a cluster name generated as {env name}-{stage name}, what alternative method should be used for generating it?

This is related to the work I am doing to convert legacy groups to clusters. Many of these groups have ASGs that are not in the {env name}-{stage name} format, which prevents the UI from rendering their cluster configurations and other UI components. In short, they just wouldn't be generated via the UI. They could be generated via API OR in this case via DB insertion (via script), which is the main reason for this PR.

My question is, how can you determine the actual ASG name if it is not generated through Teletraan and thus does not follow the {env name}-{stage name} convention?

[rfleur01]

@liyaqin1 using the format {env name}-{stage name} causes clusters that do not follow that format to not be accessible via the UI. This update leans on the cluster_name to account for names that might not be in the {env name}-{stage name}.

How do we generate the cluster name?

This does change how cluster names are generated. New clusters will still be generated in the {env name}-{stage name} format. It only adds support to get and update clusters that do not have the {env name}-{stage name}.

If the env/stage is lacking a cluster name generated as {env name}-{stage name}, what alternative method should be used for generating it?

This is related to the work I am doing to convert legacy groups to clusters. Many of these groups have ASGs that are not in the {env name}-{stage name} format, which prevents the UI from rendering their cluster configurations and other UI components. In short, they just wouldn't be generated via the UI. They could be generated via API OR in this case via DB insertion (via script), which is the main reason for this PR.

My question is, how can you determine the actual ASG name if it is not generated through Teletraan and thus does not follow the {env name}-{stage name} convention?

It's determined via group_name in the groups table. The script uses that value as the cluster name when creating the cluster record. The script also populates the cluster_name value at the env level so this PR leverages that value.

[rwxzhu]

lgtm