Open Stack

The current focus of improving the Nova Scheduler is progressing, with ResourceProviders now representing the quantities of the different resources available for virtualization. But these resources also have varying qualities that are not consumed by a VM, but describe something about the resource. The most common example is disk space, which can be consumed. This disk space can be either spinning disk or SSD, so we need to find a way to a) represent that quality and b) allow to user to specify those qualities that they desire.

We are proposing to add qualities to a ResourceProvider through the use of tags [0]. These tags are bits of text that can represent the qualities of that ResourceProvider, which can be queried in order to find those resources that have the desired qualities. In the example above, a host with SSD disk storage would have the tags ‘compute’ and ‘sad’ (among others), which would be queried for if the user asks for a VM backed by SSD.

The way that a user makes such a request will be changing, too. Instead of cramming all the possible qualitative aspects of a resource into a flavor, in the poorly-name ‘extra_specs’, the use of qualitative tags will allow flavors to be greatly simplified. In order to specify those qualitative aspects in a request, the API will add two new multi-value keys to the server request body: ‘requirements’ and ‘preferences’ [1]. As the names suggest, any quality specified in the requirements key must be present in the ResourceProvider, while any quality in the preferences key *may* will be used to select, but not disqualify, a host. In practical terms, if you specify ‘ssd’ as a requirement, you are guaranteed that the VM you get will have SSD, or the request will fail. With ‘ssd’ as a preference, though, you are not guaranteed that the VM you get will have SSD, but if any are available, you will get SSD.

Many host capabilities can be retrieved from the virt layer, and there is a proposal [2] to add a new virt method to retrieve those from the hypervisor. These can be exposed via the API, or be used to automatically tag the host’s ResourceProvider record with the appropriate tags. Some more work needs to be done to determine how to best represent the different combinations of hardware and hypervisor capabilities into something that can be standardized as much as possible (for cross-cloud interop) without severely limiting the flexibility of the design (to keep current). One such proposal along these lines [3] is to standardize these capabilities into a set of defined enums. Again, the concern is the trade-off of cloud interop vs. flexibility, as defining enums in code means that adding a new capability will require a code change, along with the necessary doc changes and review.

So we certainly have enough to discuss next week at the mid-cycle!

[0] http://lists.openstack.org/pipermail/openstack-dev/2016-July/099032.html
[1] https://review.openstack.org/313784
[2] https://review.openstack.org/#/c/286520
[3] https://review.openstack.org/#/c/309762

-- Ed Leafe