[openstack-dev] [qa][cinder] RFC: Cinder test on Tempest
ken1ohmichi at gmail.com
Wed Mar 22 22:02:51 UTC 2017
2017-03-22 14:32 GMT-07:00 Andrea Frittoli <andrea.frittoli at gmail.com>:
> On Wed, Mar 22, 2017 at 8:31 PM Sean McGinnis <sean.mcginnis at gmx.com> wrote:
>> On Wed, Mar 22, 2017 at 01:08:23PM -0700, Ken'ichi Ohmichi wrote:
>> > Hi,
>> > Now we need to update Tempest for following Cinder API status.
>> > I have an idea for restructuring and happy to see feedback about that.
>> > Now Cinder API status is
>> > V1: Deprecated
>> > V2: Deprecated
>> > V3: Current
>> > V1 API tests have been removed from Tempest side already, so we just
>> > need to concentrate on V2 and V3 now.
>> > **Gate jobs**
>> > Most Cinder tests are implemented for V2 API on Tempest side and the
>> > base microversion of V3 is the same as V2.
>> > Then we can re-use V2 API tests for the base microversion of V3 API.
>> > One idea is that we can have Cinder V3 API tests as the default on the
>> > gate jobs and the V2 API tests as another job like the following
>> > because the V2 API is deprecated.
>> > gate-tempest-dsvm-neutron-full-ubuntu-xenial - (existing job):
>> > testing Cinder V3 API
>> > gate-tempest-dsvm-py35-ubuntu-xenial - (existing job): testing Cinder
>> > V3 API
>> > ...
>> > gate-tempest-dsvm-neutron-full-ubuntu-xenial-cinder-v2: (new job):
>> > testing Cinder V2 API
> I guess this job would run against tempest and cinder only?
A nice point, I think so.
>> +1 I like this idea.
>> > We had the same testing way for Nova V2 API and V2.1 API before, and
>> > we could avoid copy&paste V2 test code for V2.1 API on Tempest.
>> > **Test Structure**
>> > Current test structure is like:
>> > tempest/api/volume/ - V2 API tests
>> > tempest/api/volume/v2 - V2 API tests
>> > tempest/api/volume/v3 - V3 API tests
>> > Yes, this is mess.
>> > For re-using V2 API tests for V3 API, it would be better to remove
>> > "v2" from V2 API tests for avoiding confusions.
>> > A new structure could be
>> > tempest/api/volume/ - All tests for V2 API and the base
>> > microversion of V3 API
>> > tempest/api/volume/v3 - V3 API specific tests for newer microversions
>> > or
>> > tempest/api/volume/ - All tests for V2 API and V3 API which
>> > includes newer microversions
>> > As the reference, Nova API structure is like the later.
>> I like the last one better as well.
> My favourite option would be that that generates less churn in the code :)
> One folder for everything means moving 4 or 5 modules only, so I think that
> be a good option.
> I would prefer to avoid though having a lot of v3 test classes that inherit
> v2 test classes, and just set _api_version = 3.
Yeah, I agree :-)
> As long as we can assume we will never run v2 and v3 in the same job, we
> have cinder_api_version as a configuration setting, to determine which
> endpoint to hit when running the volume tests.
Or it would be enough to have the existing "catalog_type",
"min_microversion" and "max_microversion" only without api_v1/v2/v3 to
control the target API version, because of the above separated gate
> Apart from the volume tests, if we split the gate jobs into standard one
> running v3
> plus and extra v2 one, we should make sure that all tests that use the
> volume API
> use a consistent version of the volume API. Nova as well should be
> configured if
> possible to use the same volume API version.
This also is a nice point.
Nova team also has a plan to use cinder v3 as the default in Pike.
We have consistent direction now.
More information about the OpenStack-dev