>> On Aug 4, 2016, at 10:48, Jay Pipes <[email protected]> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
