Open Stack

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
> would
> be a good option.
>
> I would prefer to avoid though having a lot of v3 test classes that inherit
> from
> 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
> could
> have cinder_api_version as a configuration setting, to determine which
> cinder
> 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
jobs.

> 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.

Thanks