<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 19, 2014 at 11:58 PM, David Kranz <span dir="ltr"><<a href="mailto:dkranz@redhat.com" target="_blank">dkranz@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>Removing [nova]<div class=""><br>
      <br>
      On 05/19/2014 02:55 PM, Sean Dague wrote:<br>
    </div></div><div class="">
    <blockquote type="cite">
      <pre>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></div>
    Fair enough but we need to revert, or at least stop taking patches,
    for
    <a href="https://blueprints.launchpad.net/tempest/+spec/nova-api-test-inheritance" target="_blank">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.<span class="HOEnZb"><font color="#888888"><br></font></span></div></blockquote><div><br></div><div>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:<br>
<br></div><div>- 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)<br></div><div>- class inheritance (override specific bits where necessary - bit more code, but readbility better?).<br>
</div><div>- duplicated tests (min sharing)<br></div><div><br><br></div><div>Chris<br></div><div><br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<span class="HOEnZb"><font color="#888888">
    <br>
     -David</font></span><div><div class="h5"><br>
    <blockquote type="cite">
      <pre>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>On 05/19/2014 01:24 PM, Frittoli, Andrea (HP Cloud) wrote:
</pre>
        <blockquote type="cite">
          <pre>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>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>We may have to implement support for micro-versions in tempests own rest
client as well.

andrea


-----Original Message-----
From: David Kranz [<a href="mailto:dkranz@redhat.com" target="_blank">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 href="https://etherpad.openstack.org/p/juno-nova-v3-api" target="_blank">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 href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>


_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
        </blockquote>
        <pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>

</pre>
      </blockquote>
      <pre></pre>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </div></div></div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>