On 08/03/2015 09:57 AM, Dulko, Michal wrote:
-----Original Message-----
From: Dugger, Donald D [mailto:donald.d.dug...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
