As we discussed at the mid-cycle meetup there is a bit of an issue related to host capabilities. Currently, we are overloading the flavor extra_specs with a whole lot of meaning, including requirements for specific host capabilities. Although this has allowed some impressive extension capabilities we are effectively creating an uncontrolled API that is ad hoc, ill defined and subject to arbitrary change. I think it's time to consider this in more detail and come up with a better solution.
The problem is that we have hosts with different capabilities and both users and operators need to be able to discover and control access to machines with different capabilities. Also note that, although many capabilities can be represented by simple key/value pairs (e.g. the presence of a specific special instruction) that is not true for all capabilities (e.g. Numa topology doesn't really fit into this model) and even the need to specify ranges of values (more that x byes of RAM, less than y bandwidth utilization) makes things more complex. We need to rethink how we represent and discover this information and this will potential involve an externally visible API change so it'll probably take multiple release cycles to implement something but we need to start thinking about this now. 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: 1) 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. 2) Expose the capabilities to both users and operators. 3) 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
__________________________________________________________________________ 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
