On 08/11/2016 05:50 PM, John Dickinson wrote:
On 3 Aug 2016, at 16:47, 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.
Anyway, lemme know your initial thoughts please.
Is this intended to be a cross-project thing? The message is tagged
"[nova]", so I'm kinda surprised I saw it,
Sorry about that, John. I've been focused on Nova usage at first, but
for sure I'd like the library to contain cross-project, standardized
string constants for various compute, storage, hardware, network,
device, etc capabilities. It's literally just an hour of work and
totally just spitballing ideas right now, so please don't see it as
intentionally trying to exclude anyone.
> but the library seems to
be called openstack capabilities. So if this is going to be a big
thing for everyone, please update the ML subject tag (and help me
understand how it applies to more than just nova). And if it's just
for nova (err... "compute"), then naming it something that doesn't
imply every project will need to use it could help prevent future
misunderstanding.
As Ed mentioned, this library comes from use cases in the broken-out
scheduler component (the placement API/engine) that we've been working
on in Nova this release. Once the scheduler is broken out and being used
by Nova for quantitative request matching, we will move on to supporting
the qualitative side of the request -- and that's where the capabilities
library comes into play. We are aiming to get this part of the placement
API done in Ocata and I was just getting a head start.
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
