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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
