Supporting flavor aliases

Created by: garloff

edit for the current proposal, jump to this comment

When flavor names need to change, this will cause pain for customers and operators.

• If we just rename the flavors (in the database, nova-api does not expose this), running instances and code using flavor UUIDs will be fine; however IaC code that uses the old names will fail. This may include reconciliation loops (e.g. in cluster-api), causing significant pain.
• Creating a duplicate set of flavors (one with old and one with new name) does create some UI challenges and postpones the issue to the point in time when the duplicates will be switched off ... The problem at that point in time is worse, as we'll likely have things referencing flavors that we then want to delete. Advanced database magic, which is risky.

We have this problem, as issue #190 (closed) reported that k8s based solutions create labels using the IaaS flavor names and ":" is not allowed in k8s labels. Following the reasoning in #192 (closed), a proposal exists as PR #226, where we introduce a 1:1 relationship between old and new names. The strategy to ease the transition pain however is not addressed yet.

This issue is supposed to discuss ideas how to smooth the transition for operators and their customers.