This is the follow on work for branchless tempest for new service extensions that are added over the course of a release.
In moving to branchless Tempest we’re now running Tempest across multiple OpenStack code branches. Today that’s icehouse and juno, however it will be icehouse, juno, kepler in the future.
What happens when a new extension is added to Nova in Juno, and tests in tempest are wanted for that part of the API? Today that test would fail because it could not pass icehouse.
The proposed change is to add another layer to the devstack-gate feature grid which specifies which extensions are supported at each release.
Today in the nova definition we’ve got
nova: base: services: [n-api, n-cond, n-cpu, n-crt, n-net, n-obj, n-sch]
This would imagine a world where the definition would look as follows
nova: base: services: [n-api, n-cond, n-cpu, n-crt, n-net, n-obj, n-sch] icehouse: compute-ext: [floating-ips, aggregates, ... ]
The non existence of an extensions list means assume ‘all’. It is also expected that you’d be able to specify ‘rm-compute-ext’ much like rm-services, so that you could do something as follows.
nova-cells: base: services: [n-cell] rm-compute-ext: [aggregates, hosts]
That would disable those nova extensions any time it was configured.
For this to function there needs to be changes in
Nova API microversions might obviate the need here in the branch case, as we’d be able to specify a specific test has a specific required version. However that wouldn’t solve the cells case.
The work items span projects
Only those listed above