Open Stack

On Mon, May 19, 2014 at 11:58 PM, David Kranz <dkranz at redhat.com> wrote:

>  Removing [nova]
>
>
> On 05/19/2014 02:55 PM, Sean Dague wrote:
>
> My suggestion is that we stop merging new Nova v3 tests from here
> forward. However I think until we see the fruits of the v2.1 effort I
> don't want to start ripping stuff out.
>
>  Fair enough but we need to revert, or at least stop taking patches, for
> https://blueprints.launchpad.net/tempest/+spec/nova-api-test-inheritance
> which is trying to make supporting two monolithic apis share code. We will
> share code for micro versions but it will be distributed and not based on
> class inheritance.
>

Hrm - we'll still have pretty similar issues with microversions as we do
with v2/v3 - eg the test code for the same api with a different micoversion
will have a lot in common. So for test code we're probably back to either:

- if/else inlined in tests based on the "microversion mode" that is being
tested at the moment (perhaps least amount of "code" but cost is
readability)
- class inheritance (override specific bits where necessary - bit more
code, but readbility better?).
- duplicated tests (min sharing)


Chris



>  -David
>
>  The path to removing is going to be disable Nova v3 in devstack-gate,
> when the Nova team decides it's right to do that. Once it's disconnected
> we can start the removes. Because the interface wasn't considered stable
> in icehouse, I don't think we need to keep it around for the icehouse tree.
>
> 	-Sean
>
> On 05/19/2014 07:42 AM, David Kranz 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.
>
> 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 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/20140520/ca9de2df/attachment.html>