Open Stack

2017-03-22 19:31 GMT-07:00  <zhu.fanglei at zte.com.cn>:
> To have only one folder (tempest/api/volume/ ) looks really good, and, do we
> plan to deem "api_version" and "microversion" as one thing?
>
> i.e., we will use the mechanism of microversion to skip v3 new functional
> tests when the environment only supports v2?

Yeah, that is right.
Tempest has the range of microversions with the config options
min/max_microversions and we can select the target  microversions.
If both min_microversion and max_microversion are not specified(means
None), microversion tests run as the help message[1].

So the configuration would be like

gate-tempest-dsvm-neutron-full-ubuntu-xenial - (existing job): testing
Cinder V3 API
  catalog_type: Specify Cinder V3 API's one
  min_microversion: Don't specify
  max_microversion: Specify max microversion of the branch (master, stable)

gate-tempest-dsvm-neutron-full-ubuntu-xenial-cinder-v2: (new job):
testing Cinder V2 API
  catalog_type: Specify Cinder V2 API's one
  min_microversion: Don't specify
  max_microversion: Don't specify

Thanks

---
[1]: https://github.com/openstack/tempest/blob/master/tempest/config.py#L776


> On Thu, Mar 23, 2017 at 7:02 AM, Ken'ichi Ohmichi ＜ken1ohmichi at gmail.com＞
> wrote:
>>
>> 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
>
>
> +1, this looks better as no more version specific tests and all v2 tests
> should run as it is on v3 base version.
>
>
>>
>> ＞＞ ＞
>> ＞＞ ＞ 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 :-)
>
>
>
> yea we should not have that.
>
>
>>
>>
>> ＞ 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.
>>
>
> Yes, so devstack does set different catalog for v2 and v3 [0]. Based on
> those catalog_type configured on tempest config(we already have that for
> volume API config) auth can select the right endpoints to make the API call.
>
> All existing tests can be run for both API without any extra class or
> change. This way we can get rid of 'api_version' in all volumes clients and
> have them as single copy for v2 and v3 base.
> Further v3 microversion tests can be implemented as accordingly by sending
> the microversion header on API request. and devstack can tell Temepst not to
> set microversion if catalog_type volume_v2 is being asked to run the tests.
>
> As you mentioned it can be same way we handle compute v2, v2.1 and +
> microversion tests.
>
>
>>
>> ＞ 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
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> .. 0
> http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/cinder#n403
>
> Thanks
> gmann
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>