Feat/flavor0103 add extras

[garloff]

This tool can add scs:name-v1, name-v2, cpu-type and disk0-type to existing SCS- flavors in an automated fashion. These properties are required by https://docs.scs.community/standards/scs-0103-v1-standard-flavors#properties-extra-specs To test, just call it without admin privileges :-), optionally add -d or --debug.

[garloff]

Note 1: If you create your flavors with the flavor-manager, you won't need this. Note 2: I have not checked if flavor-manager does have a mode where it will just add the missing properties (extra_specs) to existing mandatory (and recommended) flavors without changing anything else -- if it does, you may not need this little tool. Note 3: Even then, you may have additional SCS flavors where you may want to set the extra_specs according to the logic. This used to be illegal and was recently changed. I expect we will change this a little bit:

• Move the extra_specs properties to scs-0100, because it describes a scheme for these settings rather than being a property of standard flavors now.
• Introduce an additional flavor property that says: scs:status=mandatory or recommended (and leave this field out for non-prescribed SCS flavors according to scs-0103).

[garloff]

@PSwatchmen: Running this on SCS1 should make it SCS IaaS-v4 compatible.

[fkr]

Why exactly do we need this if we have the flavor manager? If the flavor manager does not suffice shouldn't we just add the missing pieces to the flavor manager instead of adding another tooling?

[garloff]

@fkr: The tools are very different: Flavor-Manager:

• flavor-manager consumes lists with all details (OSISM or SCS)
• These lists would be buggy, if we did not generate them with tooling
• flavor manager does not know about the meaning of names or extra_specs
• it will thus only ever handle the mandatory and recommended flavors that we generated for it

This tool:

• It uses the library flavor_names.py that is also used for our [compliance checks}(https://github.com/SovereignCloudStack/standards/blob/main/Tests/iaas/flavor-naming/flavor-names-openstack.py), the interactive tool and the [online tool]()https://flavors.scs.community/).
• It thus knows to interpret names and properties and knows how to check these for consistency and how to fill in missing information.
• It can do this for any flavor that follows the SCS- rules, not just the mandatory and recommended flavors from 0103.

[frosty-geek]

I agree that this is either a "side-car" tool of the flavor manager and thus should live in said git repo, or even better should be a function of the flavor manager itself and able to "update" those flavors that it is configured to create (obviously there is a way to do this)

[mbuechse]

The properties in question are not required, except for the standard flavors, and I would highly recommend using the OSISM flavor manager. It can indeed just set the extra_specs for those flavors that already exist, and while the spec file used by the flavor manager could be erroneous due to the flavor manager being agnostic to our flavor naming, the spec file provided in this repo is being checked by our continuous-integration pipeline.

So this new tool is mainly useful for flavors beyond the list of standard flavors, which is perfectly okay. But it only sets the main part and the disk part of the flavor name. This does seem a bit restricted to me. Besides, we might be getting a new revision of the standard https://docs.scs.community/standards/iaas/scs-0103 which will also include the property scs:name-v3 -- see this PR. BTW, this new revision expressly states that new versions of scs-0100 shall deal with the name property in the future.

[garloff]

The properties in question are not required, except for the standard flavors, and I would highly recommend using the OSISM flavor manager.

Agreed.

It can indeed just set the extra_specs for those flavors that already exist, and while the spec file used by the flavor manager could be erroneous due to the flavor manager being agnostic to our flavor naming, the spec file provided in this repo is being checked by our continuous-integration pipeline.

Well we generate the input to the flavor manager, so this should not be error-prone.

So this new tool is mainly useful for flavors beyond the list of standard flavors, which is perfectly okay. But it only sets the main part and the disk part of the flavor name. This does seem a bit restricted to me.

It does not have more information, because OpenStack does not expose much in standardized ways. So this would need to be passed by the user.

Besides, we might be getting a new revision of the standard https://docs.scs.community/standards/iaas/scs-0103 which will also include the property scs:name-v3 -- see this PR. BTW, this new revision expressly states that new versions of scs-0100 shall deal with the name property in the future.

Ack.