Since this is a long email, I think this quick summary is in order. The gate/check jobs in Trove are facing a problem [1] which was fixed [2]. The fix has issues and I am looking for input from other projects who may have faced this problem.
How does a project with a controller and a client ensure that the version of client and backend are in sync, not only in master but also in stable branches? The current approach in Trove has problems, and the generally recommended approach leads to some issues. So I am looking for input from other projects to learn how they address it, and to get opinions on a proposal for how I intend to fix this issue in Trove. Excruciating details follow. -- The project openstack/trove has a client component openstack/python-troveclient just like many other projects do. When a change is made that straddles the controller and the client, they need to be merged together. With the new cross project dependencies, this has become much easier. The reviews for the change to the client and the controller are linked (depends-on) and therefore they both go in. Tests in the controller require the use of the client and exercise the client as well. Once the changes merge, tests got the right client because the test-requirements.txt file had a line like this: http://tarballs.openstack.org/python-troveclient/python-troveclient-master.tar.gz#egg=python-troveclient A recent change to the client exposed a problem; the test-requirements.txt file(s) in stable/kilo and stable/liberty also had the same line! Therefore they were (had been) using the wrong requirements.txt file. So, fixes [3] and [4] were proposed to address the issue in the stable branches. Basically with the proposed changes, stable branches would pin to a tarball of the appropriate vintage. In speaking with Doug Hellmann, I learned that this wasn't the right approach and the correct thing would be for the client to be released more often (to pypi) and then the test-requirements.txt would have to just pin specific releases. This approach requires that we weould have to release the client more often, and there would be a period of time between when the client was merged and submitted to pypi, and the time when the controller merged when there would be functionality in the client with no back-end support. Question: How do other projects handle this? If you have experience doing this for other projects, I would appreciate your thoughts on this approach. If you have pointers about LIBS_FROM_GIT, please do send them along, other than [5], that is. I would also like input on the proposal below, for how Trove would address this. 1. Master would use LIBS_FROM_GIT and therefore would always get the tip of master. I still need to figure out how exactly to use this but I'm told (thanks again to Doug Hellmann) that this is something that some other projects use. 2. When a stable branch is cut, test-requirements.txt will have a specific version of the python-troveclient specified. This will eliminate the hack of specifying a tarfile and the attendant problems. Thanks, -amrith [1] https://bugs.launchpad.net/trove/+bug/1539818 [2] https://review.openstack.org/#/c/274345/ [3] https://review.openstack.org/#/c/274797/ [4] https://review.openstack.org/#/c/252584/6/test-requirements.txt [5] http://docs.openstack.org/developer/devstack/configuration.html -- Amrith Kumar, CTO | amr...@tesora.com Tesora, Inc | @amrithkumar 125 CambridgePark Drive, Suite 400 | http://www.tesora.com Cambridge, MA. 02140 | GPG: 0x5e48849a9d21a29b
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
