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