<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Removing [nova]<br>
<br>
On 05/19/2014 02:55 PM, Sean Dague wrote:<br>
</div>
<blockquote cite="mid:5379F129.6080400@dague.net" type="cite">
<pre wrap="">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.</pre>
</blockquote>
Fair enough but we need to revert, or at least stop taking patches,
for
<a class="moz-txt-link-freetext" href="https://blueprints.launchpad.net/tempest/+spec/nova-api-test-inheritance">https://blueprints.launchpad.net/tempest/+spec/nova-api-test-inheritance</a><br>
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.<br>
<br>
-David<br>
<blockquote cite="mid:5379F129.6080400@dague.net" type="cite">
<pre wrap="">
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:
</pre>
<blockquote type="cite">
<pre wrap="">On 05/19/2014 01:24 PM, Frittoli, Andrea (HP Cloud) wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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
</pre>
<blockquote type="cite">
<pre wrap="">
We may have to implement support for micro-versions in tempests own rest
client as well.
andrea
-----Original Message-----
From: David Kranz [<a class="moz-txt-link-freetext" href="mailto:dkranz@redhat.com">mailto:dkranz@redhat.com</a>]
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:
<a class="moz-txt-link-freetext" href="https://etherpad.openstack.org/p/juno-nova-v3-api">https://etherpad.openstack.org/p/juno-nova-v3-api</a>.
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 list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>