Add the ability to have an alias on a Stage (and have it be visible in the UI)

[blakepettersson]

Checklist

• [x] I've searched the issue queue to verify this is not a duplicate feature request.
• [ ] I've pasted the output of kargo version, if applicable.
• [ ] I've pasted logs, if applicable.

Proposed Feature

Customers have expressed the desire to be able to display custom metadata (most notably aliases) directly in the UI.

Motivation

This would be used to set a (non-unique) alias on the stage itself. This could be useful when you have multiple pipelines, but you also want the stages to be named similarly through all pipelines. This could be the starting point to extend this for other metadata, but that's an exercise for later.

Suggested Implementation

Add an extra kargo.akuity.io/alias annotation field which would be used in the UI to override the default stage name (but only in the UI). Other annotations could be added for visual purposes at a later stage.

[jessesuen]

This has been discussed before, and rather than a feature to create alias for an alias, we want users to be able to more prominently see what is running in each stage, without having to mentally map from the alias:

https://github.com/akuity/kargo/issues/3770#issuecomment-2782910123

[nikolay-te]

This has been discussed before, and rather than a feature to create alias for an alias, we want users to be able to more prominently see what is running in each stage, without having to mentally map from the alias:

#3770 (comment)

I think this issue refers to aliasing the stage name, not necessarily having to do with the current freight/versions running. One example is a monorepo with a few microservices each deploying to the same set of kubernetes clusters. If we want to have all these microservices in the same Kargo project as separate pipelines we can't use the kubernetes cluster names as stage names as they won't be unique.

[krancour]

Apologies... the confusion here is probably my fault, as when this was raised in an internal meeting yesterday, I latched onto the word "alias" and the discussion went from there. 😓

You are correct that this issue is not the same as the perennial issue of customizable Freight aliases.

There is probably room for discussion here, although I will be quick to point out that non-unique aliases, while not the least bit technically difficult, seem likely to introduce new UX complications.

If we want to have all these microservices in the same Kargo project as separate pipelines we can't use the kubernetes cluster names as stage names as they won't be unique.

fwiw, except in certain scenarios, cluster names probably aren't the best things to be incorporating into Stage names. Ourselves, we more commonly name Stages like foo-test, foo-qa, foo-prod, bar-test, bar-qa, bar-prod. i.e. Names more commonly denoting purpose than physical location.

[nikolay-te]

Apologies... the confusion here is probably my fault, as when this was raised in an internal meeting yesterday, I latched onto the word "alias" and the discussion went from there. 😓

You are correct that this issue is not the same as the perennial issue of customizable Freight aliases.

There is probably room for discussion here, although I will be quick to point out that non-unique aliases, while not the least bit technically difficult, seem likely to introduce new UX complications.

If we want to have all these microservices in the same Kargo project as separate pipelines we can't use the kubernetes cluster names as stage names as they won't be unique.

fwiw, except in certain scenarios, cluster names probably aren't the best things to be incorporating into Stage names. Ourselves, we more commonly name Stages like foo-test, foo-qa, foo-prod, bar-test, bar-qa, bar-prod. i.e. Names more commonly denoting purpose than physical location.

The issue is we have many of those :) There are multiple instances of the same application for dev, staging, uat and prod and each instance usually has two stages as a DR pair, and we encode the purpose in the cluster name, so essentially each stage is named after the cluster.

[krancour]

The issue is we have many of those :) There are multiple instances of the same application for dev, staging, uat and prod and each instance usually has two stages as a DR pair, and we encode the purpose in the cluster name, so essentially each stage is named after the cluster.

All of that makes sense.

I am curious about what potential issues you see if all of the sudden you have multiple Stages all presenting themselves as "dev."

It feels as if it's an open invitation to cases of mistaken identity. Imagine accidentally promoting to the wrong "dev."

How do you see this working out without creating such problems?

[github-actions[bot]]

This issue has been automatically marked as stale because it had no activity for 90 days. It will be closed if no activity occurs in the next 30 days but can be reopened if it becomes relevant again.

[github-actions[bot]]

This issue has been automatically marked as stale because it had no activity for 90 days. It will be closed if no activity occurs in the next 30 days but can be reopened if it becomes relevant again.