Flavor specs: Add extra_specs standardization

[garloff]

While we have the capability to encode lots of details in the flavor names (also see discussion at #73), we often will have cloud providers without such a huge variety in hardware and thus flavors. So no need to use all the optional suffixes; instead the provider would be well advised to stick to the generic shorter (and memorable) flavor names.
Nevertheless, there should be a way to communicate more details than are generally available in the flavor API (which is ram, vcpus, disk). There is a field extra_specs that could be used for this. This will need to be standardized.

[garloff]

See
https://docs.openstack.org/api-guide/compute/extra_specs_and_properties.html

[garloff]

https://docs.openstack.org/nova/latest/configuration/extra-specs.html

[garloff]

Also an upstream topic (Public Cloud SIG):
https://etherpad.opendev.org/p/publiccloud-sig-meeting
https://etherpad.opendev.org/p/publiccloud-sig-specs

[artificial-intelligence]

so, what exactly is the list of extra specs we want to standardize?

I feel this is handwaved away too much:

is ram, vcpu, disk sufficient?

there are many more extra_specs defined upstream, like numa stuff, even IPv4 addresses.

what is the benefit of standardizing this, if we only copy verbatim a strict subset of upstreams possible values?

I'd argue that the construct of extra_specs is already highly implementation specific, that is, it is afaik only available in openstack and will continue to be only available there.

So while I think it is worthwhile to point to extra_specs, when customers want to specify images in more details, I don't see immediate benefit in copying a random subset of upstreams possible values for extra_specs and call that a standard :edit: until we can present an argument why these blessed extra_specs are extremly important and the others are not.

[mbuechse]

I find the OpenStack documentation rather confusing. At one point it states

The key-value pairs used must correspond to well-known options

At another point it states

While there are standard extra specs, deployments can define their own extra specs to be used with host aggregates and custom scheduler filters as necessary

The list of well-known options is long, and some of the public cloud people seem to advise using them, but there are qualifications attached to many of these options, such as "only supported by the libvirt virt driver", and I don't know whether that is a problem for us.

Addendum: It doesn't help the confusion that the CLI tool seems to refer to these extra specs as "properties". The CLI tool itself seems to be rather poorly documented as well. :(

[fkr]

I'll add a longer commentary based on the outcomes of the nova operator hour of the Caracal vPTG here later and elaborate on why a different way of pursuing this is what upstream suggested.