[openstack-dev] [qa][cinder] RFC: Cinder test on Tempest

Sean McGinnis sean.mcginnis at gmx.com
Wed Mar 22 20:27:41 UTC 2017


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
> 

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

> 
> Any thoughts?
> 
> Thanks
> Ken Ohmichi
> 
> __________________________________________________________________________
> 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



More information about the OpenStack-dev mailing list