Open Stack

On 05/20/2014 03:19 PM, Christopher Yeoh wrote:
> On Tue, May 20, 2014 at 8:58 PM, Sean Dague <sean at dague.net 
> <mailto:sean at 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 at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140520/0b95b152/attachment.html>