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
__________________________________________________________________________
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
