<div dir="ltr">I also agree that instead of removing the old test, we keep changing those as microversion gets changed.<div>One suggestion (may be same as what Chris is thinking)-</div><div>-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.</div>
<div>-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.<br><div class="gmail_extra" style>For example-</div>
<div class="gmail_extra" style><img src="cid:ii_1461bd83863561a7" alt="Inline image 1" width="462" height="274"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br>
</div><div class="gmail_extra">-- <br><div dir="ltr"><div>Thanks</div><div>Ghanshyam Mann</div></div><br><div class="gmail_quote">On Mon, May 19, 2014 at 9:39 PM, Christopher Yeoh <span dir="ltr"><<a href="mailto:cbkyeoh@gmail.com" target="_blank">cbkyeoh@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
On Mon, May 19, 2014 at 9:12 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div>
    <div>On 05/19/2014 01:24 PM, Frittoli,
      Andrea (HP Cloud) wrote:<br>
    </div>
    <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></div>
    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<br>
    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. <br></div></blockquote><div><br><br></div><div>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.<br>

<br></div><div>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.<br>

</div><div><br></div><div>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.<br>

</div><div><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">

    <br>
    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.<span><font color="#888888"><br>
    <br>
     -David</font></span><div><div><br>
    <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>
</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" target="_blank">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>
<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><br clear="all"><div><br></div><br><div dir="ltr"><div><br></div></div>
</div></div></div>