Re: [openstack-dev] [qa][nova] Status of v3 tests in tempest

[GHANSHYAM MANN]

I agree to continue work on  bp/ nova-api-test-inheritance. As its reduce
the duplication code and later will help to remove the V2 tests easily.
V2.1 tests can be written on same design of inheritance.

-- 
Thanks
Ghanshyam Mann

On Mon, May 19, 2014 at 9:32 PM, Kenichi Oomichi
wrote:

> Hi David,
>
> > -Original Message-
> > From: David Kranz [mailto:dkr...@redhat.com]
> > Sent: Monday, May 19, 2014 6:49 PM
> > 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.
>
> I agree to stop new Nova v3 tests and disable Nova v3 tests in
> the gate for icehouse.
> and I hope we continue working for reducing duplication between
> Nova v2/v3 tests on bp/ nova-api-test-inheritance. Because it
> would be nice for v2.1 API tests also for avoiding duplication
> between v2/v2.1 tests also.
>
>
> Thanks
> Ken'ichi Ohmichi
>
>
> ___
> 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

Re: [openstack-dev] [qa][nova] Status of v3 tests in tempest

[GHANSHYAM MANN]

I also agree that instead of removing the old test, we keep changing those
as microversion gets changed.
One suggestion (may be same as what Chris is thinking)-
-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.
-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.
For example-
[image: Inline image 1]



-- 
Thanks
Ghanshyam Mann

On Mon, May 19, 2014 at 9:39 PM, Christopher Yeoh  wrote:

> On Mon, May 19, 2014 at 9:12 PM, 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.
>>
>
>
> 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.
>
> 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.
>
> 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.
>
>
>
>> 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 ]
>> 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 supporti

Re: [openstack-dev] [qa][nova] Status of v3 tests in tempest

[David Kranz]

On 05/20/2014 03:19 PM, Christopher Yeoh wrote:
On Tue, May 20, 2014 at 8:58 PM, Sean Dague > wrote:


On 05/19/2014 11:49 PM, Christopher Yeoh wrote:
>>
> - 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)

Realistically, the current approach won't scale to micro versions. We
really won't be able to have 100 directories for Nova, or a 100 class
inheritances.

When a micro version happens, it will affect a small number of
interfaces. So the important thing will be testing those interfaces
before and after that change. We'll have to be really targeted here.
Much like the way the database migration tests with data injection
are.

Honestly, I think this is going to be hard to fully map until
we've got
an interesting version sitting in front of us.


So I agree that we won't be able to have a new directory for every 
microversion. But for the v2/v3 changes

we already have a lot of typical minor changes we'll need to handle. Eg.

- a parameter that has been renamed or removed (effectively the same 
thing from an API point of view)

- a success status code that has changed

Something like say a tasks API would I think be quite different 
because there would be a lot less shared code for the tests and so 
we'll need a different solution.


I guess what I'm saying is once we have a better idea of how the 
microversion interface will work then I think doing the work to 
minimise the code duplication on the tempest side is worth it because 
we have lots of examples of the sorts of cases we'll need to handle.


I agree. I think what Sean is saying, and this was the original intent 
of starting this thread, is that the structure we come up with for micro 
versions will look a lot different than the v2/v3 consolidation that was 
in progress in tempest when the decision to abandon v3 as a monolithic 
new api was made. So we have to stop the current changes based on a 
monolithic v2/v3, and then come up with a new organization based on 
micro versions when the nova approach has solidified sufficiently.


 -David



Regards,

Chris

-Sean

--
Sean Dague
http://dague.net


___
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


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa][nova] Status of v3 tests in tempest

[Christopher Yeoh]

On Tue, May 20, 2014 at 8:58 PM, Sean Dague  wrote:

> On 05/19/2014 11:49 PM, Christopher Yeoh wrote:
> >>
> > - 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)
>
> Realistically, the current approach won't scale to micro versions. We
> really won't be able to have 100 directories for Nova, or a 100 class
> inheritances.
>
> When a micro version happens, it will affect a small number of
> interfaces. So the important thing will be testing those interfaces
> before and after that change. We'll have to be really targeted here.
> Much like the way the database migration tests with data injection are.
>
> Honestly, I think this is going to be hard to fully map until we've got
> an interesting version sitting in front of us.
>
>
So I agree that we won't be able to have a new directory for every
microversion. But for the v2/v3 changes
we already have a lot of typical minor changes we'll need to handle. Eg.

- a parameter that has been renamed or removed (effectively the same thing
from an API point of view)
- a success status code that has changed

Something like say a tasks API would I think be quite different because
there would be a lot less shared code for the tests and so we'll need a
different solution.

I guess what I'm saying is once we have a better idea of how the
microversion interface will work then I think doing the work to minimise
the code duplication on the tempest side is worth it because we have lots
of examples of the sorts of cases we'll need to handle.

Regards,

Chris



> -Sean
>
> --
> Sean Dague
> http://dague.net
>
>
> ___
> 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

Re: [openstack-dev] [qa][nova] Status of v3 tests in tempest

[Sean Dague]

On 05/19/2014 11:49 PM, Christopher Yeoh wrote:
> 
> 
> 
> On Mon, May 19, 2014 at 11:58 PM, David Kranz  > 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)

Realistically, the current approach won't scale to micro versions. We
really won't be able to have 100 directories for Nova, or a 100 class
inheritances.

When a micro version happens, it will affect a small number of
interfaces. So the important thing will be testing those interfaces
before and after that change. We'll have to be really targeted here.
Much like the way the database migration tests with data injection are.

Honestly, I think this is going to be hard to fully map until we've got
an interesting version sitting in front of us.

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa][nova] Status of v3 tests in tempest

[Christopher Yeoh]

On Mon, May 19, 2014 at 11:58 PM, David Kranz  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 ]
> 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
>
>
>
> ___
> OpenSt

Re: [openstack-dev] [qa][nova] Status of v3 tests in tempest

[David Kranz]

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.


 -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]
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 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



___
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


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa][nova] Status of v3 tests in tempest

[Christopher Yeoh]

On Mon, May 19, 2014 at 9:12 PM, 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.
>


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.

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.

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.



> 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 ]
> 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 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

Re: [openstack-dev] [qa][nova] Status of v3 tests in tempest

[Kenichi Oomichi]

Hi David,

> -Original Message-
> From: David Kranz [mailto:dkr...@redhat.com]
> Sent: Monday, May 19, 2014 6:49 PM
> 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.

I agree to stop new Nova v3 tests and disable Nova v3 tests in
the gate for icehouse.
and I hope we continue working for reducing duplication between
Nova v2/v3 tests on bp/ nova-api-test-inheritance. Because it
would be nice for v2.1 API tests also for avoiding duplication
between v2/v2.1 tests also.


Thanks
Ken'ichi Ohmichi


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa][nova] Status of v3 tests in tempest

[Sean Dague]

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.

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] 
>> 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 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
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa][nova] Status of v3 tests in tempest

[David Kranz]

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]
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 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


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa][nova] Status of v3 tests in tempest

[Frittoli, Andrea (HP Cloud)]

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.

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] 
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 list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [qa][nova] Status of v3 tests in tempest

[David Kranz]

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 list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev