Open Stack

On 08/12/2016 04:05 AM, Daniel P. Berrange wrote:
> On Wed, Aug 03, 2016 at 07:47:37PM -0400, Jay Pipes wrote:
>> Hi Novas and anyone interested in how to represent capabilities in a
>> consistent fashion.
>>
>> I spent an hour creating a new os-capabilities Python library this evening:
>>
>> http://github.com/jaypipes/os-capabilities
>>
>> Please see the README for examples of how the library works and how I'm
>> thinking of structuring these capability strings and symbols. I intend
>> os-capabilities to be the place where the OpenStack community catalogs and
>> collates standardized features for hardware, devices, networks, storage,
>> hypervisors, etc.
>>
>> Let me know what you think about the structure of the library and whether
>> you would be interested in owning additions to the library of constants in
>> your area of expertise.
>
> How are you expecting that these constants are used ? It seems unlikely
> the, say nova code, code is going to be explicitly accessing any of the
> individual CPU flag constants.

These capability strings are what deployers will associate with a flavor 
in Nova and they will be passed in the request to the placement API in 
either a "requirements" or a "preferences" list. In order to ensure that 
two OpenStack clouds refer to various capabilities (not just CPU flags, 
see below), we need a curated list of these standardized constants.

 > It should surely just be entirely metatadata
> driven - eg libvirt driver would just parse libvirt capabilities XML and
> extract all the CPU flag strings & simply export them.

You are just thinking in terms of (lib)virt/compute capabilities. 
os-capabilities intends to provide a standard set of capability 
constants for more than virt/compute, including storage, network devices 
and more.

But, yes, I imagine discovery code running on a compute node with the 
*libvirt* virt driver could indeed simply query the libvirt capabilities 
XML snippet and translate those capability codes into os-capabilities 
constants. Remember, VMWare and Hyper-V also need to do this discovery 
and translation to a standardized set of constants. So does 
ironic-inspector when it queries an IPMI interface of course.

 > It would be very
> undesirable to have to add new code to os-capabilities every time that
> Intel/AMD create new CPU flags for new features, and force users to upgrade
> openstack to be able to express requirements on those CPU flags.

I don't see how we would be able to expose a particular new CPU flag 
*across disparate OpenStack clouds* unless we have some standardized set 
of constants that has been curated. Not all OpenStack clouds run 
libvirt. And again, think bigger than just virt/compute.

Best,
-jay

>> Next steps for the library include:
>>
>> * Bringing in other top-level namespaces like disk: or net: and working with
>> contributors to fill in the capability strings and symbols.
>> * Adding constraints functionality to the library. For instance, building in
>> information to the os-capabilities interface that would allow a set of
>> capabilities to be cross-checked for set violations. As an example, a
>> resource provider having DISK_GB inventory cannot have *both* the disk:ssd
>> *and* the disk:hdd capability strings associated with it -- clearly the disk
>> storage is either SSD or spinning disk.
>
> Regards,
> Daniel
>