Open Stack

> -----Original Message-----
> From: Jay Pipes [mailto:jaypipes at gmail.com]
> Sent: Friday, August 12, 2016 2:20 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova] os-capabilities library created
> 
> 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.
[Mooney, Sean K] just as an aside I think Libvirt actually gets its capability
Information from udev. Again that wont help you on windows but it's at least not
Requiring Libvirt.  os-capabilities could retrieve info via udev also potentially.

Ipmi will allow you to discover some capabilities of the system but
It might be worth considering redfish fit for capabilities discovery
http://www.dmtf.org/standards/redfish
https://www.brighttalk.com/webcast/9077/163783

On a personal note could we call os-capabilities, os-caps?
Its shorter and  I have misspelled capabilities 4 different ways in typing this 
Response which I have now fixed it.
> 
> 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: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev