[openstack-dev] How should we expose host capabilities to the scheduler

Chris Friesen chris.friesen at windriver.com
Mon Aug 10 15:22:23 UTC 2015


On 08/10/2015 08:05 AM, Jay Pipes wrote:

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

I think it would make sense for an end user to be able to specify something like 
"my image requires at least a Sandybridge virtual processor or better to run 
properly".  Now from what I understand vendors sometimes mask out CPU features 
for some reason, so it might actually be necessary to do something like "my 
image requires at least a Sandybridge or better, and I specifically want to make 
sure that CPU features X, Y, and Z are enabled".

Maybe this could work with what you suggest above in that if the requirement 
isn't met by the "service level" then the user gets a nice error message saying 
they need to set a particular service level or better.

Chris



More information about the OpenStack-dev mailing list