[openstack-dev] [nova] os-capabilities library created
jaypipes at gmail.com
Fri Aug 12 01:13:41 UTC 2016
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
>> 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
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.
More information about the OpenStack-dev