Open Stack

On 08/03/2015 09:57 AM, Dulko, Michal wrote:
>> -----Original Message-----
>> From: Dugger, Donald D [mailto:donald.d.dugger at intel.com]
>> Sent: Monday, August 3, 2015 7:40 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] How should we expose host capabilities to the
>> scheduler
>>
>> Without going into the solution space the first thing we need to do is make
>> sure we know what the requirements are for exposing host capabilities.  At a
>> minimu we need to:
>>
>> Enumerate the capabilities.  This will involve both quantitative values
>> (amount of RAM, amount of disk, .) and Boolean (magic instructions
>> present).  Also, there will be static capabilities that are discovered at boot
>> time and don't change afterwards and dynamic capabilities that vary during
>> node operation.
>> Expose the capabilities to both users and operators.
>> Request specific capabilities.  A way of requesting an instance with an explicit
>> list of specific capabilities is a minimal requirement.  It would probably also be
>> good to have a way to easily specify an aggregate that encompasses a set of
>> capabilities.
>>
>> Note that I'm not saying we should remove flavors, but we might need a
>> different way to specify what makes up a flavor.
>>
>> As I said, I don't have the answer to how to do this but I want to start a
>> discussion on where we go from here.
>>
>> --
>> Don Dugger
>> "Censeo Toto nos in Kansa esse decisse." - D. Gale
>> Ph: 303/443-3786
>
> There already is a Glance Metadata Catalog which is enumerating and exposing different meaningful extra_specs that can be attached to a flavor. The list of capabilities is defined here: https://github.com/openstack/glance/tree/master/etc/metadefs. Example definition of flavor extra_specs: https://github.com/openstack/glance/blob/master/etc/metadefs/compute-host-capabilities.json.

The Glance metadefs stuff is problematic in a number of ways:

1) It wasn't written with Nova in mind at all, but rather for UI needs. 
This means it introduces a bunch of constants that are different from 
the constants in Nova.

2) It uses a custom JSON format instead of JSONSchema, so we now need to 
figure out the schema for these metadef documents and keep up to date 
with that schema as it changes.

3) It mixes qualitative things -- CPU model, features, etc -- with 
quantitative things -- amount of cores, threads, etc. These two things 
are precisely what we are trying to decouple from each other in the next 
generation of Nova's "flavors".

4) It is still missing the user-facing representation of these things. 
Users -- i.e. the people launching VMs in Nova -- do not want or need to 
know whether the underlying hardware is running Nehalem processors or 
Sandybridge processors. They only need to know the set of generic 
features that are exposed to the workloads running on the host. In other 
words, we are looking for a way to map "service levels" such as "Silver 
Compute" or "Whizbang Amazing Compute" to a set of hardware that exposes 
some features. We need that compatibility layer on top of the low-level 
hardware specifics that will allow service providers to create these 
"product categories" if you will.

Best,
-jay