Open Stack

On Wednesday morning Jay Pipes led a double session on the work going on 
in the Nova scheduler. The session etherpad is here [1].

Jay started off by taking us through a high-level overview of what was 
completed for the quantitative changes:

1. Resource classes

2. Resource providers

3. Online data migration of compute node RAM/CPU/disk inventory.

Then Jay talked through the in-progress quantitative changes:

1. Online data migration of allocation fields for instances.

2. Modeling of generic resource pools for things like shared storage and 
IP subnet allocation pools (for Neutron routed networks).

3. Creating a separate placement REST API endpoint for generic resource 
pools.

4. Cleanup/refactor around PCI device handling.

For the quantitative changes, we still need to migrate the PCI and NUMA 
fields.

In the second scheduler session we got more into the capabilities 
(qualitative) part of the request. For example, this could be exposing 
hypervisor capabilities from the compute node through the API or for 
scheduling.

Jay pointed out there have been several blueprints posted over time 
related to this.

We discussed just what a capability is, i.e. is a hypervisor version a 
capability since certain features are only exposed with certain 
versions?  For libvirt it isn't really. For example, you can only set 
the admin password in a guest if you have libvirt >=1.2.16. But for 
hyper-v there are features which are supported by both older and newer 
versions of the hypervisor but are generally considered better or more 
robust in the newer version. But for some things, like supporting 
hyperv-gen2 instances, we consider that 'supports-hyperv-gen2' is the 
capability. We can further break that down by value enums if we need 
more granular information about the capability.

While informative, we left the session with some unanswered next steps:

1. Where to put the inventories/allocations tables. We have three 
choices: API DB, Nova (cell) DB, or a new placement DB. Leaving them in 
the cell DB would mean aggregating data which would be a mess. Putting 
them in a new placement DB would mean a 2nd new database in a short 
number of releases for deployers to manage. So I believe we agreed to 
put them in the API DB (but if others think otherwise please speak up).

2. We talked for quite awhile about what a capability is and isn't, but 
I didn't come away with a definitive answer. This might get teased out 
in Claudiu's spec [2]. Note, however, that on Friday we agreed that as 
far as microversions are concerned, a new capability exposed in the REST 
API requires a microversion. But new enumerations for a capability, e.g. 
CPU features, do not require a new microversion bump, there are just too 
many of them.

3. I think we're in agreement on the blueprints/roadmap that Jay has put 
forth, but it's unclear if we have an owner for each blueprint. Jay and 
Chris Dent own several of these and some others are helping out (Dan 
Smith has been doing a lot of the online data migration patches), but we 
don't have owners for everything.

4. We need to close out any obsolete blueprints from the list that Jay 
had in the etherpad. As already noted, several of these are older and 
probably superseded by current work, so the team just needs flush these out.

5. Getting approval on the generic-resource-pools, 
resource-providers-allocations, standardizing capabilities (extra 
specs). The first two are pretty clear at this point, the specs just 
need to be rebased and reviewed in the next week. A lot of the code is 
already up for review. We're less clear on standardizing capabilities.

--

So the focus for the immediate future is going to have to be on 
completing the resource providers, inventory and allocation data 
migration code and generic resource pools. That's all the quantitative 
work and if we can push to get a lot of that done before the midcycle 
meetup it would be great, then we can see where we sit and discuss more 
about capabilities.

Jay - please correct or add to anything above.

[1] https://etherpad.openstack.org/p/newton-nova-scheduler
[2] https://review.openstack.org/#/c/286520/

-- 

Thanks,

Matt Riedemann