Über Open CoDE Software Wiki Diskussionen GitLab

Skip to content

Revise flavor naming standard according to review criticism

Created by: 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 https://github.com/SovereignCloudStack/standards/pull/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?