Open Stack

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?


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

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.




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


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.

andrea
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170322/005e992e/attachment.html>