Non-mandatory SCS-XXX flavors may confuse users.

[garloff]

According to current standards (SCS-compatible IaaS v5.1), providers MAY provide flavors to customers beyond the mandatory (and recommended) set of flavors, yet follow the SCS- naming scheme.
Customers relying on SCS- named flavors may assume that their workloads are portable, despite using non-mandatory (and even non-recommended) SCS- named flavors.

We could change the prefix to SCSx (or some other SCS variation) to make it visible, but there are numerous issues around handling the transition then.

This proposal follows a different approach and adds another meta data (extra_specs) field that makes it transparent. Tools as well as humans could look at it.

Technically, this breaks compliance of existing clouds, so we'd need a -v2 rather than a -v1.3 for scs-0103. It depends a bit on the implementation details, so let's have the discussion before creating a v2.

Some other notes:

• The fact that scs:name-vX, scs:cpu-type, scs:diskN-type (and the new scs:required) are specified in scs-0103 makes them a requirement only for the mandatory (and recommended) flavors, not for other SCS- named flavors. This makes tooling more difficult to get right for users. I would thus recommend moving this to the scs-0100 standard and thus force all flavors following the SCS naming convention must have the metadata, simplifying user tooling. This would result in an scs-0100-v4 ... and scs-0103 could stay at v1.3. If we decide against the move: I have added one note where 0100 references 0103 that the extra_specs are defined there.
• We could also do tricks like disallowing some scs: metadata for non-mandatory/recommended flavors, using this as an indicator. While this would save some database space, I would avoid this, mixing two concepts (a property meant to improve technical discoverability and a property indicating the portability) together and making it harder to process by a human brain.