Flavor naming adjustment considerations

Created by: garloff

In issue #190 (closed) we learn that OpenShift is using IaaS flavor names as k8s annotations (taints or tolerations?). This means that in order for OpenShift to run well on SCS IaaS, adjustments need to be made. At this point, OpenShift is the only tool known to us that imposes such restrictions on IaaS choices, but we need to watch out for other restrictions that may come down from tools in the k8s world.

Assuming that we need to adjust our own flavor spec, thus following option 3 in https://github.com/SovereignCloudStack/standards/issues/190#issuecomment-1403346954, we have a few options:

3a) We make an easy transformation: e.g. SCS-2V:8:20s-GNa:64 to SCS-2V_8_20s_GNa_64 (s/:/_/g) or SCS-2V-8-20s_GNa-64 (sed -e 's/-/_/g' -e 's/:/-/g' -e 's/^SCS_/SCS-/') (2vCPU, 8Gib RAM, 20GB SSD, passthrough GPU nVidia Ampere with 64 SMs) 3b) We reevaluate our approach to systematic flavor naming, resulting in a new schema that can not be easily machine-translated.

The transition will be painful for existing providers and customers. In any case a transition strategy will need to be implemented, with transition periods, where the old flavor names will still be accepted (e.g. by being translated or by offering flavors under both new and old name).

The advantage of 3a is that we can easily machine-translate, so user settings/automation can be easily adjusted. We could even translate at the API interface to make things smoother.