introduce scs-0103-v1 v1.1 (backwards compatible, compliance-preservi…

…ng) (#677)

Signed-off-by: Matthias Büchse <[email protected]>

Standards/scs-0103-v1-standard-flavors.md

@@ -14,6 +14,19 @@ description: |
 
 ## Introduction
 
+This is v1.1 of the standard, which lifts the following restriction regarding the property `scs:name-vN`:
+this property may now be used on any flavor, rather than standard flavors only. In addition, the "vN" is
+now interpreted as "name variant N" instead of "version N of the naming standard". Note that this change
+indeed preserves compliance, i.e., compliance with v1.0 implies compliance with v1.1.
+
+## Terminology
+
+extra_specs
+  Additional properties on an OpenStack flavor, see
+  [OpenStack Nova user documentation](https://docs.openstack.org/nova/2024.1/user/flavors.html#extra-specs)
+  and
+  [OpenStack Nova configuration documentation](https://docs.openstack.org/nova/2024.1/configuration/extra-specs.html).
+
 ## Motivation
 
 In OpenStack environments there is a need to define different flavors for instances.
@@ -23,13 +36,13 @@ OpenStack providers thus typically offer a large selection of flavors.
 While flavors can be discovered (`openstack flavor list`), it is helpful for users (DevOps teams),
 to have a guaranteed set of flavors available on all SCS clouds, so these need not be discovered.
 
-## Properties (extra specs)
+## Properties (extra_specs)
 
-The following extra specs are recognized, together with the respective semantics:
+The following extra_specs are recognized, together with the respective semantics:
 
-- `scs:name-vN=NAME` (where `N` is `1` or `2`, and `NAME` is some string) means that the
-  flavor is one of the
-  standard SCS flavors, and the requirements of Section "Standard SCS flavors" below apply.
+- `scs:name-vN=NAME` (where `N` is a positive integer, and `NAME` is some string) means that
+  `NAME` is a valid name for this flavor according to any major version of the [SCS standard on
+  flavor naming](https://docs.scs.community/standards/iaas/scs-0100).
 - `scs:cpu-type=shared-core` means that _at least 20% of a core in >99% of the time_,
   measured over the course of one month (1% is 7,2 h/month). The `cpu-type=shared-core`
   corresponds to the `V` cpu modifier in the [flavor-naming spec](./scs-0100-v3-flavor-naming.md),
@@ -43,6 +56,24 @@ The following extra specs are recognized, together with the respective semantics
 
 Whenever ANY of these are present on ANY flavor, the corresponding semantics must be satisfied.
 
+The extra_spec `scs:name-vN` is to be interpreted as "name variant N". This name scheme is designed to be
+backwards compatible with v1.0 of this standard, where `scs:name-vN` is interpreted as
+"name according to naming standard vN". We abandon this former interpretation for two reasons:
+
+1. the naming standards admit multiple (even many) names for the same flavor, and we want to provide a means
+   of advertising more than one of them (said standards recommend using two: a short one and a long one),
+2. the same flavor name may be valid according to multiple versions at the same time, which would lead to
+   a pollution of the extra_specs with redundant properties; for instance, the name
+   `SCS-4V-16` is valid for both [scs-0100-v2](scs-0100-v2-flavor-naming.md) and
+   [scs-0100-v3](scs-0100-v3-flavor-naming.md), and, since it does not use any extension, it will be valid
+   for any future version that only changes the extensions, such as the GPU vendor and architecture.
+
+Note that it is not required to use consecutive numbers to number the name variants.
+This way, it becomes easier to remove a single variant (no "closing the gap" required).
+
+If extra_specs of the form `scs:name-vN` are used to specify SCS flavor names, it is RECOMMENDED to include
+names for the latest stable major version of the standard on flavor naming.
+
 ## Standard SCS flavors
 
 Following are flavors that must exist on standard SCS clouds (x86-64).
@@ -127,14 +158,19 @@ instance life cycle.)
 
 ## Conformance Tests
 
-The script `flavors-openstack.py` will read the lists of mandatory and recommended flavors
+The script [`flavors-openstack.py`](https://github.com/SovereignCloudStack/standards/blob/main/Tests/iaas/standard-flavors/flavors-openstack.py)
+will read the lists of mandatory and recommended flavors
 from a yaml file provided as command-line argument, connect to an OpenStack installation,
-and check whether the flavors are present and their extra specs are correct. Missing
-flavors will be reported on various logging channels: error for mandatory, info for
-recommended flavors. Incorrect extra specs will be reported as error in any case.
+and check whether the flavors are present and their extra_specs are correct.
+
+Missing flavors will be reported on various logging channels: error for mandatory, warning for
+recommended flavors. Incorrect extra_specs will be reported as error in any case.
 The return code will be non-zero if the test could not be performed or if any error was
 reported.
 
+The script does not check whether a name given via the extra_spec `scs:name-vN` is indeed valid according
+to any major version of the SCS standard on flavor naming.
+
 ## Operational tooling
 
 The [openstack-flavor-manager](https://github.com/osism/openstack-flavor-manager) is able to

Tests/iaas/standard-flavors/flavors-openstack.py

@@ -148,7 +148,7 @@ def main(argv):
                     logger.warning(f"Flavor '{flavor_spec['name']}' found via name only, missing property {es_name_key!r}")
                 else:
                     status = flavor_spec['_group']['status']
-                    level = {"mandatory": logging.ERROR}.get(status, logging.INFO)
+                    level = {"mandatory": logging.ERROR}.get(status, logging.WARNING)
                     logger.log(level, f"Missing {status} flavor '{flavor_spec['name']}'")
                     continue
             # this flavor has a matching spec