[openstack-dev] [nova] os-capabilities library created
jaypipes at gmail.com
Sun Aug 14 17:31:51 UTC 2016
Word up, Travis :) A few comments inline, but overall I'm looking
forward to collaborating with you, Steve, and all the other Searchlight
contributors on os-capabilities (or os-caps as Sean wants to rename it ;)
On 08/11/2016 08:00 PM, Tripp, Travis S wrote:
> [Graffit] was originally co-sponsored by Intel
> to help expose out all the CPU capabilities in Nova. The constants in
> the metadef catalog all come from combing through the code in Nova
> was a complete maze and were not available at the time from
> Nova (or cinder or glance or …) See overview here :
>  https://wiki.openstack.org/wiki/Graffiti
Yep, I'm thoroughly familiar with the maze-ishness of the code in Nova
and os-capabilities was borne out of an attempt to curate/catalog a
number of collections of string metadata, constants spread over modules,
and various hardcoded feature flags/strings in the virt drivers and
>> 2) It uses a custom JSON format instead of JSONSchema, so we now need to
>> figure out the schema for these metadef documents and keep up to date
>> with that schema as it changes.
> It uses JSON schema, but surrounds it with a very lightweight envelope.
> The envelope is called a namespace and is simply a container of JSON
> schema, allowing us to manage it as a programmatic unit and as a way
> for cloud deployers to share the capabilities across clouds very easily.
> We did place a limitation on it that it cannot support nested objects. This
> was primarily due to the extreme difficulty of representing that construct
> to users in an easy to understand way:
I actually do not think there is a need for a JSON schema for any of the
capability strings in os-caps. I wasn't planning on supporting anything
more than simple strings with a string prefix for "namespaces" and a
common delimiter (I chose ':'). I'd like to keep things as simple as
>> 3) It mixes qualitative things -- CPU model, features, etc -- with
>> quantitative things -- amount of cores, threads, etc. These two things
>> are precisely what we are trying to decouple from each other in the next
>> generation of Nova's "flavors".
I noticed you didn't respond to this part of my email (from a year ago).
It's actually a really important point. The mixing of quantitative and
qualitative things in the Nova flavor extra specs as well as the Glance
metadefs stuff is a real problem we're trying to fix with the new
More information about the OpenStack-dev