Open Stack

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.

Best,
-jay