Please correct me if I'm wrong, but I think this needs to happen on RCs not on 
CI tests.

Couple of possible problems I personally see with this approach:
1) Extensive pressure to push new client releases (perhaps the released client 
is not as good as intended for just to provide someone tools to get through 
2) Un-necessary slowing of development. If the needed client functionality is 
merged but not released, the commits using this functionality will fail. This 
IMO fights against the point of having CI as we're still depending on internal 
releases during the development process.
3) More skipped tests "waiting" for client release and not catching the real 
4) over time LIBS_FROM_GIT just cumulates having all used clients rendering the 
effort useless anyways.

I do agree that we need to catch the scenarios driving you towards this on 
whatever we call Stable, but anything out of that should not be affected just 
because project does not release monthly, weekly or daily client versions.

I might have missed something here, but I just don't see the correlation  of 
unreleased server depending unreleased client being problem.

- Erno

> -----Original Message-----
> From: Sean Dague []
> Sent: 28 October 2014 12:29
> To:
> Subject: [openstack-dev] [all] using released versions of python clients in
> tests
> At the beginning of the month we moved through a set of patches for oslo
> libs that decoupled them from the integrated gate by testing server projects
> with released versions of oslo libraries.
> The way it works is that in the base devstack case all the oslo libraries are
> pulled from pypi instead of git. There is an override LIBS_FROM_GIT that lets
> you specify you want certain libraries from git instead.
> * on a Nova change oslo.config comes from the release pypi version.
> * on an olso.config change we test a few devstack configurations with
> LIBS_FROM_GIT=oslo.config, so that we can ensure that proposed
> olso.config changes won't break everyone.
> I believe we should do the same with all the python-*client libraries as well.
> That will ensure that servers don't depend on unreleased features of python
> client libraries, and will provide the forward testing to ensure the next
> version of the python client to be released won't ruin the world.
> This is mostly a heads up that I'm going to start doing this implementation. 
> If
> someone wants to raise an objection, now is the time.
> However I think breaking this master/master coupling of servers and clients
> is important, and makes OpenStack function and upgrade a bit closer to what
> people expect.
>       -Sean
> --
> Sean Dague
> _______________________________________________
> OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to