-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flavor specs: Add extra_specs standardization #74
Comments
Also an upstream topic (Public Cloud SIG): |
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 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 |
I find the OpenStack documentation rather confusing. At one point it states
At another point it states
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. |
@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. |
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 : It seems, that all these traits and inventories should be set through the automatic inspection, which is done by nova compute. |
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.
The text was updated successfully, but these errors were encountered: