On Jun 2, 2015, at 5:58 AM, Alexis Lee <[email protected]> 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 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. So did I miss anything? :) -- Ed Leafe
signature.asc
Description: Message signed with OpenPGP using GPGMail
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
