Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140519/90f4a9b6/attachment.html>