Open Stack

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