SovereignCloudStack
Flavor specs: Add extra_specs standardization
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.
See https://docs.openstack.org/api-guide/compute/extra_specs_and_properties.html
Also an upstream topic (Public Cloud SIG): https://etherpad.opendev.org/p/publiccloud-sig-meeting https://etherpad.opendev.org/p/publiccloud-sig-specs
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.
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. :(
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.
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.
@fkr it has been some time since you announced to add a comment here. Take it as a reminder or maybe you even do not want to make this comment anymore, however just to make some progress here and not to create a "blocker", please tell us about your decision on that comment soon.
@cah-patrickthiem Felix won't be back before August 7. Maybe @gtema can elaborate on the issue?
currently @gtema is working on a discoverability service for exactly this topic. The spec can be found here: https://review.opendev.org/c/openstack/publiccloud-sig/+/909387/9/specs/discoverability_service.rst We discussed today in the Public Cloud SIG, that there is one open question: How / When does the mapping from the hardware to the software in placement takes place? And who has to do this in which way? Unfortunately the OpenStack documentation does not seem to answer these questions completely. We will have to investigate this and hopefully come up with either a documentation or a guide for CSPs on how to integrate certain physical features into the placement traits.
Actually there is one single sentence describing how traits are generated by nova-compute in https://docs.openstack.org/placement/latest/user/index.html#tracking-resources : "The nova resource tracker in nova-compute is responsible for creating the resource provider record corresponding to the compute host on which the resource tracker runs, setting the inventory that describes the quantitative resources that are available for workloads to consume (e.g., VCPU), and setting the traits that describe qualitative aspects of the resources (e.g., STORAGE_DISK_SSD)."
It seems, that all these traits and inventories should be set through the automatic inspection, which is done by nova compute.