Sean, 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 tests). 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 issues. 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 [mailto:s...@dague.net] > Sent: 28 October 2014 12:29 > To: firstname.lastname@example.org > 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 > http://dague.net > > _______________________________________________ > OpenStack-dev mailing list > OpenStackemail@example.com > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev