On Mon, May 19, 2014 at 11:58 PM, David Kranz <dkr...@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:dkr...@redhat.com <dkr...@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@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing > listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing > listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing > listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
