In re: user specifying requirements Note that we have 2 different requirements here:
1) The cloud user needs to be able to specify "I want to run this image on a machine that supports capability `foo'". 2) The cloud provider needs to be able to say "If you want capability `foo' it'll cost you". The cloud provider needs to be able to provide tiers of service with appropriate pricing models for those different tiers. Note that the pricing tier issues means that we have to be careful about how the user asks for capabilities. If we bury that into the image meta-data then the user could unexpectedly find himself implicitly asking for a pricier instance than expected. -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale Ph: 303/443-3786 -----Original Message----- From: Chris Friesen [mailto:[email protected]] Sent: Monday, August 10, 2015 9:22 AM To: [email protected] Subject: Re: [openstack-dev] How should we expose host capabilities to the scheduler 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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
