On 3 June 2015 at 13:53, Ed Leafe <e...@leafe.com> wrote: > On Jun 2, 2015, at 5:58 AM, Alexis Lee <alex...@hp.com> wrote: > >> If you allocate all the memory of a box to high-mem instances, you may >> not be billing for all the CPU and disk which are now unusable. That's >> why flavors were introduced, afaik, and it's still a valid need. > > So we had a very good discussion at the weekly IRC meeting for the Scheduler, > and we agreed to follow that up here on the ML. One thing that came up, noted > in the quote above, is that I gave the impression in my first email that I > thought flavors were useless. I think I did a better job in the original blog > post of explaining that flavors are a great way to handle the sane division > of a resource like a compute node. The issue I have with flavors is that we > seem to be locked into the "everything that can be requested has to fit into > the flavor", and that really doesn't make sense. > > Another concern was from the cloud provider's POV, which makes a flavor a > convenient way of packaging cloud resources for sale. The customer can simply > say "give me one of these" to specify a complex combination of virtualized > resources. That's great, but it means that there has to be a flavor for every > possible permutation of resources. If you restricted flavors to only > represent the sane ways of dividing up compute nodes, any other features > could be add-ons to the request. Something like ordering a pizza: offer the > customer a fixed choice of sizes, but then let them specify any toppings in > whatever combination they want. That's certainly more sane than presenting > them with a menu with hundreds of pizza "flavors", each representing a > different size/topping combination.
I feel there is a lot to be said for treating "consumable" resources very separately to "free" options. For example grouping the vCPUs into sockets can be "free" in terms of capacity planning, so is a valid optional add on (assuming you are not doing some level of pinning to match that). For things where you are trying to find a specific compute node, that kind of attribute has clear capacity planning concerns, and is likely to have a specific "cost" associated with it. So we need to make sure its clear how that cost concept can be layered on top of the Nova API. For example "os_type" often changes the cost, and is implemented on top of flavors using a combination of protected image properties on glance and the way snapshots inherit image properties. >> I totally agree the scheduler doesn't have to know anything about >> flavors though. We should push them out to request validation in the >> Nova API. This can be considered part of cleaning up the scheduler API. > > This idea was also discussed and seemed to get a lot of support. Basically, > it means that by the time the request hits the scheduler, there is no > "flavor" anymore; instead, the scheduler gets a request for so much RAM, so > much disk, etc., and these amounts have already been validated at the API > layer. So a customer requests a flavor just like they do now, and the API has > the responsibility to verify that the flavor is valid, but then "unpacks" the > flavor into its components and passes that on to compute. The end result is > the same, but there would be no more need to store "flavors" anywhere but the > front end. This has the added benefit of eliminating the problem with new > flavors being propagated down to cells, since they would no longer need to > have to translate what "flavor X" means. Don Dugger volunteered to write up a > spec for removing flavors from the scheduler. > +1 for Nova translating the incoming request to a "resource request" the scheduler understands, given the resources it knows about. I would look at scoping that to "compute" resources, so its easier to add "volume" and "network" into that request at a later date. Thanks, John __________________________________________________________________________ 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
