Split flavor naming and mandatory flavors in two separate standards

[anjastrunk]

Flavor naming and mandatory flavors are currently defined in one standard, called flavor naming, but should be separated.

[mbuechse]

Just so I get this right: the split should be done in both V1 and V2, shouldn't it? I'm afraid I'm a little confused here, because our table (see SovereignCloudStack/docs#29) lists V1 as done and V2 as draft, while the file structure in the repo suggests the opposite: V1 being a draft and V2 being done. Is it okay then to split the V2 document, or would this then constitute a new version?

[mbuechse]

Just so I get this right: the split should be done in both V1 and V2, shouldn't it? I'm afraid I'm a little confused here, because our table (see SovereignCloudStack/docs#29) lists V1 as done and V2 as draft, while the file structure in the repo suggests the opposite: V1 being a draft and V2 being done. Is it okay then to split the V2 document, or would this then constitute a new version?

@garloff Can you maybe comment on this?

[garloff]

v1 was created before we had SCS-0001 done, so it does not fully comply to the standard how we create standards 🫢
That's why it was never moved to the Standards directory. But it was (and currently still is) a valid standard, so this is indeed misleading. We should copy it over to Standards/0100-v1

v2 still needs to receive the stabilized status.

There is an ongoing discussions, see #271, which we should conclude (hopefully by May 8) before the stabiliszation can happen.

I would not split v1. But we can create two new standards 0102-v2 and 0103-v2 that supercede 0100-v2.

[mbuechse]

@garloff Is that something we should quickly do before the next team IaaS meeting tomorrow, or would it be better suited when the discussion on Wednesday is done?

[mbuechse]

In the spirit of separation of concerns and loose coupling, it would be nice if we could list the mandatory/recommended flavors without referring to the names; BUT: this could only work if the relevant properties could be discovered from the flavor resource, which (currently) seems quite far away.

More generally: Which flavor properties are discoverable (from the flavor resource), which properties are at least testable (poking one or more instances)?

• List of all flavor properties present in scs-0100-v3-flavor-naming:
  • #vCPUs: discoverable, testable
  • vCPU dedicated/oversubscribed [C/T/V/L]: testable ?
  • insecure microcode [i]: testable ?
  • RAM in GiB: discoverable, testable
  • absence of ECC [u]: ??
  • RAM oversubscribed [o]: testable ?
  • #disks: testable
  • disk size in GB: discoverable, testable
  • disk type [n/h/s/p]: testable ?
  • hypervisor (or bare metal): testable ?
  • hardware virtualization capability (nested virt): testable ?
  • CPU vendor: testable ?
  • CPU generation: testable ?
  • CPU clock speed class: testable ?
  • GPU virtualized/passthrough: ??
  • GPU vendor: testable ?
  • GPU generation: testable ?
  • #vGPUs: discoverable ?, testable
  • Infiniband networking: ??
• The docs list quite a few extra_specs that could match some of these properties. Examples:
  • trait:STORAGE_DISK_SSD=required,
  • hw:cpu_policy=dedicated,
  • resources:VGPU=12
• But these extra_specs don't seem to be widely adopted! And they already tie in with placement and scheduler filters, but we want customer-facing info.
• If discoverability and testability are so poor, what role could Gaia-X self-descriptions play?
  • those would at least be attested and signed, as opposed to the flavor resources themselves

[fkr]

Is being worked on in the PR #319 - synchronous discussion before next iaas call if need be to be scheduled by @fkr