Open Stack

I also agree that instead of removing the old test, we keep changing those
as microversion gets changed.
One suggestion (may be same as what Chris is thinking)-
-Tempest can keep the common test directory containing tests which are
going to be same as microversion bump up. Initially all test can go to
common directory and keep filtering the variant tests as microversion
progress.
-As microversion gets changed, tempest will override the tests for those
API which are being changed and will run the other common tests also for
this Test version.
For example-
[image: Inline image 1]



-- 
Thanks
Ghanshyam Mann

On Mon, May 19, 2014 at 9:39 PM, Christopher Yeoh <cbkyeoh at gmail.com> wrote:

> On Mon, May 19, 2014 at 9:12 PM, David Kranz <dkranz at redhat.com> wrote:
>
>>  On 05/19/2014 01:24 PM, Frittoli, Andrea (HP Cloud) wrote:
>>
>> Thanks for bringing this up.
>>
>> We won't be testing v3 in Juno, but we'll need coverage for v2.1.
>>
>> In my understanding will be a v2 compatible API - so including proxy to
>> glance cinder and neutron - but with micro-versions to bring in v3 features
>> such as CamelCase and Tasks.
>> So we should be able to reuse a good chunk of the v3 test code for testing
>> v2.1. Adding some config options for the v2.1 to v3 differences we could try
>> and use the same tests for icehouse v3 and juno v2.1.
>>
>>  While it is true that we may reuse some of the actual test code
>> currently in v3, the overall code structure for micro-versions will be
>> much different than for a parallel v2/v3. I wanted to make sure every
>> one  on the qa list knows that v3 is being scrapped and that we should stop
>> making changes that are intended only to enhance the maintainability of an
>> active v2/v3 scenario.
>>
>
>
> So I think we need to distinguish between "v3 being scrapped" and "v3
> features being scrapped". I think its likely that most of the v3
> cleanups/features will end up being exposed via client microversions (its
> what I sort of asked about near the end of the session). And by removing
> the tests we will inevitably end up with regressions which we don't want to
> happen.
>
> I think its pretty important we sort out the microversion design on the
> Nova side pretty quickly and we could adapt the existing v3 tempest tests
> to instead respond with a very high version microversion number. As we roll
> out new features or accept v3 changes in Nova with microversions,
> individual tests can then be changed to respond to the lower microversion
> numbers. That way we keep existing regression tests so we don't regress on
> the Nova side and don't need to rewrite them at a later date for tempest.
> Depending on how the client microversion design works this might make code
> duplication issues on the tempest side easier to handle - though we're
> going to need a pretty generic solution to support API testing of
> potentially quite a few versions of individual APIs as depending on the
> microversion.  Every time we bump the microversion we essentially just add
> a new version to be tested, we don't replace the old one.
>
> There is one big implication for tempest regarding micoversions for Nova -
> scenario testing. With microversions we need to support testing for quite a
> few versions of slightly different APIs rather than just say 2. And there's
> some potential for quite a few different combinations especially if other
> projects go the microversion route as well.
>
>
>
>> With regard to icehouse, my understanding is that we are basically
>> deprecating v3 as an api before it was ever declared stable. Should we
>> continue to carry technical debt in tempest to support testing the unstable
>> v3 in icehouse? Another alternative, if we really want to continue testing
>> v3 on icehouse but want to remove v3 from tempest, would be to create a
>> stable/icehouse branch in tempest and run that against changes to
>> stable/icehouse in projects in addition to running tempest master.
>>
>>  -David
>>
>>  We may have to implement support for micro-versions in tempests own rest
>> client as well.
>>
>> andrea
>>
>>
>> -----Original Message-----
>> From: David Kranz [mailto:dkranz at redhat.com <dkranz at redhat.com>]
>> Sent: 19 May 2014 10:49
>> To: OpenStack Development Mailing List
>> Subject: [openstack-dev] [qa][nova] Status of v3 tests in tempest
>>
>> It seems the nova team decided in Atlanta that "v3" as currently understood
>> is never going to exist:https://etherpad.openstack.org/p/juno-nova-v3-api.
>>
>> There are a number of patches in flight that tweak how we handle supporting
>> both v2/v3 in tempest to reduce duplication.
>> We need to decide what to do about this. At a minimum, I think we should
>> stop any work that is inspired by any v3-related activity except to revert
>> any v2/v3 integration that was already done. We should really rip out the v3
>> stuff that was recently added. I know Matt had some concern about that
>> regarding testing v3 in stable/icehouse but perhaps he can say more.
>>
>>   -David
>>
>> _______________________________________________
>> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140521/c7df21dc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 12749 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140521/c7df21dc/attachment.png>