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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
