[BUG] do not mark additional flavors as an error

[berendt]

We have additional flavors which are not listed in the SCS standard and which contain all the necessary metadata. If these are present, they should not be marked as errors. The names of the flavors are valid according to the SCS standard.

ERROR: The following flavors are not standard, yet use a reserved property: SCS-2V-4-20: scs:name-v1, scs:name-v2, SCS-4V-8-50s: scs:name-v1, scs:name-v2, SCS-4V-8-50: scs:name-v1, scs:name-v2, SCS-8V-32-50: scs:name-v1, scs:name-v2, SCS-8V-64: scs:name-v1, scs:name-v2, SCS-1V-1-10: scs:name-v1, scs:name-v2

[mbuechse]

The test simply does what the standard says:

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.

[berendt]

But does that make sense? I would like to define flavors according to the SCS standard, but they are not specified as recommended or must in the standard. IMO, it makes sense to include all SCS meta information for these flavors as well.

[berendt]

@garloff Please have a look. We were supposed to discuss it today, but there wasn't time. Our v4 check is currently red as we are adding SCS metadata to flavors that are not listed as mandatory or recommended. I think that should be fine to provide additional flavors. At the moment, we're just not really sure how this is intended in the standard.

[mbuechse]

Kurt asked me via e-mail about the rationale, and I think it's not unappropriate to also reproduce my response here:

• this standard was only a first shot at standardizing the extra_specs, so we wanted to gather some experience with it before rolling it out more widely;

• one of the aims of this standard and the extra_specs was to obviate the need for flavor names in the first place (which need careful parsing, for instance, to differentiate between _i for Intel and _ib for Infiniband), so we didn't want to proliferate those;

• only the mandatory and recommended flavors can be counted on to be present in general, so those can be found by name; all the other flavors would have to be selected in a more advanced manner, and then we can as well use the other extra_specs instead of the name.

• the names for the mandatory and recommended flavors are listed in the same standard, whereas for all other names, one would have to refer to the standard about flavor naming, and this would pose two problems:

  1. the standard would no longer be self-contained (with consequences for the test scripts); and
  2. which major version to refer to?

We would have to refer to some major version, or we would have to introduce some complicated mechanism by which it could be inferred from the context which one would apply. The context could be the certificate scope, but then these two realms would start bleeding into each other, which feels messy to me.

[mbuechse]

As discussed yesterday both in personal conversation and the SIG Std/Cert, it seems that this part of the standard (however many reasons it may have) doesn't work for the customers, so with the associated Pull Request we relax the test so as no longer to enforce said part.