Revise flavor naming standard according to review criticism

[mbuechse]

@artificial-intelligence made a few pertinent remarks on PR 319 that actually apply to the current version of the flavor naming standard and, so far as they are only editorial in nature, could and should be implemented there.

This is the list of remarks from the PR (mostly verbatim, so the pronoun "I" refers to Sven):

typos and minor changes

(edit: already resolved via #331)

• Change typo ti to to in line 58.
• Change typo suffices to suffixes in lines 285.

FIXMEs lines 215, 216:

- SCS-2C-4-3x- <- Cloud decides disk type and size and creates three of them (FIXME: Is this useful?)
- SCS-2C-4-3xs <- Cloud decides size and creates three local SSD volumes (FIXME: useful?)

this should be decided: is it useful? I honestly don't know.
if nobody does: remove it?

Dealing with transition from v1 to v2 names

Lines 492/493:

Considerations for how providers can ensure a smooth transition for their customers from v1 to v2 are written in a separate document.

can we directly link to said document?

(Remark from mbuechse: I guess it still doesn't exist yet, but I don't know)

Allowing for missing flavors

Lines 222--224:

To be certified as an SCS compliant x86-64 IaaS platform, you must offer all standard mandatory SCS
flavors according to the previous section. (We may define a mechanism that allows exceptions to be
granted in a way that makes this very transparent and visible to clients.)

imho this document at least needs to formally specify how this mechanism would be constructed, otherwise it's a 100% escape hatch where some org process can grant exception on practically no basis.

i.e.

• who can define this mechanism (team iaas?)
• how? (majority vote?)
• how is this decision made transparent (meeting minutes, voting protocol) and recorded

(Remark from mbuechse: There is no such mechanism. The whole "we may define" is actually an entirely vacuous statement. Don't interpret too much into it.)

is it really advisable to allow insecure flavors at all?

I also see a problem regarding future new vulnerabilities.

what if a previously deemed secure flavor is suddenly insecure (new vulnerability discovered) until a new patch is developed, which can take months/years.

we/the csp can't rename the flavor, but that would mean the csp isn't standard compatible, so all vulnerable flavors need to be deleted and need to be recreated.

I'm just asking: is this really what we want?

At least I find the wording unclear here, what does these mitigations reference here? the previous sentence is not about mitigations but about oversubscription.

line 122 on one hand talks about generic cpu vulnerabilities but on the other hand about very specific mitigations like microcode updates, disabling hyperthreading and the L1TF vulnerability.

so is the insecure flavor naming flag only for already previously known vulnerabilities or should it also be retroactively applied when new vulnerabilities are discovered and are not - yet - patched?

[garloff]

FIXMEs lines 215, 216:

• SCS-2C-4-3x- <- Cloud decides disk type and size and creates three of them (FIXME: Is this useful?)
• SCS-2C-4-3xs <- Cloud decides size and creates three local SSD volumes (FIXME: useful?)

this should be decided: is it useful? I honestly don't know.
if nobody does: remove it?

This was considered an option and has not found any use in real life.
So yes, let's remove it.

[garloff]

Dealing with transition from v1 to v2 names

Lines 492/493:

Considerations for how providers can ensure a smooth transition for their customers from v1 to v2 are written in a separate document.

can we directly link to said document?

The attempts to write a recommendation up was unfortunately thwarted by fundamental opposition to having a naming standard at all. When that was finally resolved, the providers already had worked out their way to do the transition.
So no, we have no official recommendation for this.
Medium-term the approach to encode metadata and also alternative names into extra_spec fields, enhancing the API to make them searchable and then ensuring that IaC tools such as ansible, open-terraform or the openstack-cli use it.

[garloff]

Allowing for missing flavors

Lines 222--224:

To be certified as an SCS compliant x86-64 IaaS platform, you must offer all standard mandatory SCS
flavors according to the previous section. (We may define a mechanism that allows exceptions to be
granted in a way that makes this very transparent and visible to clients.)

imho this document at least needs to formally specify how this mechanism would be constructed, otherwise it's a 100% escape hatch where some org process can grant exception on practically no basis.

i.e.

who can define this mechanism (team iaas?)
how? (majority vote?)
how is this decision made transparent (meeting minutes, voting protocol) and recorded

We have not spelled this fully out, as correctly noted. Here are my thoughts:

As SCS moves to more specialized environments, e.g. edge deployments, we may find clouds that work according to all SCS standards except not having the ability to offer large flavors (by nature of the hardware, maybe not even being x86 based). If this creates lots of differences, we would probably define a separate certification profile (e.g. "SCS IaaS-compatible RISC-V-Edge" or so). If there is just a minor deviation, we might instead opt for an exception process:

The decision would be an ADR itself and thus follow the well documented SCS-0001 process.
The relevant teams would be involved: SIG std, team IaaS (for IaaS stds) would have to agree. As it's a matter of protecting the SCS brand, the SCS PO/CTO would also have the right to veto.
As you can see, the process is to avoid exceptions, not to grant them.

More importantly, at the place where we display the SCS-compatible clouds, we would make the exception visible.

[garloff]

is it really advisable to allow insecure flavors at all?

I also see a problem regarding future new vulnerabilities.

what if a previously deemed secure flavor is suddenly insecure (new vulnerability discovered) until a new patch is developed, which can take months/years.

Well, we require cloud providers to deploy the available mitigations within a month, not to deploy mitigations that are not yet available.

we/the csp can't rename the flavor, but that would mean the csp isn't standard compatible, so all vulnerable flavors need to be deleted and need to be recreated.

I'm just asking: is this really what we want?

I am indeed expecting cloud providers to keep their cloud secure. By using the flavor names without the i insecure indicator, they commit to keeping them secure.
So deploying the microcode, hypervisor fixes, kernel fixes, even when this is painful (e.g. costing performance or requiring to switch off hyperthreading for certain CPUs).
They can however offer higher performance insecure flavors in addition, if they really see a market demand.

At least I find the wording unclear here, what does these mitigations reference here? the previous sentence is not about mitigations but about oversubscription.

line 122 on one hand talks about generic cpu vulnerabilities but on the other hand about very specific mitigations like microcode updates, disabling hyperthreading and the L1TF vulnerability.

so is the insecure flavor naming flag only for already previously known vulnerabilities or should it also be retroactively applied when new vulnerabilities are discovered and are not - yet - patched?

No. it applies to all publically known vulnerabilities. As said, the clock ticks as soon as there are mitigations available from upstream.

[mbuechse]

@garloff Should we modify the document so as to avoid the same questions popping up again?

• Remove the two flavor name examples, so much you already suggested.
• Drop the sentence about smooth transition from v1 to v2 as it's kind of obsolete?
• Regarding the missing flavors, maybe clarify that this intention is in no way authoritative but a future avenue for those providers who cannot comply with these terms, maybe mention that this would require a dedicated ADR/standard document and maybe even a separate type of certificate (instead of SCS-compatible IaaS, SCS-compatible IaaS on Edge)?
• I don't know, maybe we can make the wording more clear regarding the commitment to implement all mitigations IF and WHEN they exist.

[garloff]

Hi @mbuechse - yes all of your suggestions make sense to me. (And they would not even require a new version number as they are merely clarifications.)

[mbuechse]

@garloff I made the changes discussed above, with one exception: I dropped the whole paragraph

-To be certified as an SCS compliant x86-64 IaaS platform, you must offer all standard mandatory SCS
-flavors according to the previous section. (We may define a mechanism that allows exceptions to be
-granted in a way that makes this very transparent and visible to clients.)

because I think this is a matter of the certification not the standard. In general, to receive a certain
certificate, you have to comply with all standards that belong to that certificate.

edit Amendment: Also, the whole matter of standard flavors is going to split off anyway (see #267) ;)