On 05/20/2014 03:19 PM, Christopher Yeoh wrote:
On Tue, May 20, 2014 at 8:58 PM, Sean Dague <s...@dague.net
<mailto:s...@dague.net>> 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
<mailto: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
