[openstack-dev] [nova] os-capabilities library created

Jim Rollenhagen jim at jimrollenhagen.com
Fri Aug 5 03:05:18 UTC 2016

>> On Aug 4, 2016, at 10:48, Jay Pipes <jaypipes at gmail.com> wrote:
>>> On 08/04/2016 10:31 AM, Jim Rollenhagen 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.
>>> 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.
>> Well, if we constrain ourselves to VMs, yes. :)
> I wasn't constraining ourselves to VMs :)
>> One of the issues with running ironic behind nova is that there isn't
>> any way to express that a flavor (or instance) has (or should have)
>> multiple physical disks. It would certainly be possible to boot a
>> baremetal machine that does have SSD and spinning rust.
>> I don't have a solution in mind here, just wanted to point out that we
>> need to keep more than VMs in mind when talking about capabilities. :)
> Note that in the above, I am explicit that the disk:hdd and disk:ssd capabilities should not be provided by a resource provider **that has an inventory of DISK_GB resources** :)
> Ironic baremetal nodes do not have an inventory record of DISK_GB. Instead, the resource class is dynamic -- e.g. IRON_SILVER. The constraint of not having disk:hdd and disk:ssd wouldn't apply in that case.

Touché. I would like to be able to express that some baremetal resource class can have disk:ssd and disk:hdd capabilities, but it sounds like that's covered. Thanks for clearing that up for me. :)

// jim

> Best,
> -jay
> __________________________________________________________________________
> 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

More information about the OpenStack-dev mailing list