Open Stack

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                   | amrith at tesora.com
Tesora, Inc                         | @amrithkumar
125 CambridgePark Drive, Suite 400  | http://www.tesora.com
Cambridge, MA. 02140                | GPG: 0x5e48849a9d21a29b 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160204/419bfa78/attachment.pgp>