Open Stack

Hi,

Now Nova and Ironic have implemented API microversions in Kilo.
Nova's microversions are v2.1 - v2.3.
Ironic's microversions are v1.1 - v1.6.

Now Tempest is testing the lowest microversion on the gate, and
Ironic's microversions test patch[1] is on the gerrit.
Before merging the patch, I'd like to propose consistent test way for
microversions of Nova and Ironic.

My suggestion is the test target microversions are:
* the lowest microversion
* the biggest microversion, but don't use the keyword "latest" on a
header and these microversions tests are operated on different gate
jobs.

The lowest microversion is already tested on check-tempest-dsvm-full
or something, so this proposes just to add the biggest microversion
job like check-tempest-dsvm-full-big-microversion.

[background]
In long-term, these microversions continue increasing and it is
difficult to run Tempest for all microversions on the gate because of
test workload. So I feel we need to select microversions which are
tested on the gate for efficient testing.

[the lowest microversion]
On microversion mechanism, if a client *doesn't* specify favorite
microversion in its request header, a Nova/Ironic server considers the
request as the lowest microversion. So the lowest microversion is
default behavior and important. I think we need to test it at least.

[the biggest microversion]
On microversion mechanism, if a client specify the keyword "latest" in
its request header instead of microversion, a Nova/Ironic server works
on the biggest microversion behavior.
During the development, there is time lag between each project dev and
Tempest dev. After adding a new API on a project, corresponding tests
are added to Tempest in most cases. So if specifying the keyword
"latest", Tempest would not handle the request/response and fail,
because Tempest can not catch the latest API changes until
corresponding Tempest patch is merged.
So it is necessary to have the target microversion config option in
Tempest and pass specific biggest microversion to Tempest with
openstack-infra/project-config.

Any thoughts?

Thanks
Ken Ohmichi
---
[1]: https://review.openstack.org/#/c/166386/