openstack team mailing list archive

[Monty Taylor <mordred@xxxxxxxxxxxx>]

Dealing with the client libraries has become a little bit of a tricky
subject, which is both lacking consistency and direction - but is kind
of essential to the project. (a service without a client library isn't
nearly as useful) At UDS this past week, Joe Heck, Jim Blair and I sat
down for a while and worked through a bunch of the issues and would like
to propose the following:

- Each project that exposes an API should have a separate client library
project. For instance, python-novaclient, python-glanceclient, etc.

- Each of these projects will have its own top-level git repo and be
managed by gerrit just like a core project.

- The python-*client project will be under the purvue of the PTL for the
main project (mainly so that we don't have an explosion of PTLs all of a
sudden)

- Each client library project will release milestones and final releases
on the same schedule as the rest of the core projects.

- The client libraries will release directly to PyPI at final release
time. If we do this, releasing the need to release main core projects to
PyPI is obviated (which is good, as we do not expect anyone to actually
install a running OpenStack from PyPI - but it is reasonable to expect
people to want to use client libraries from PyPI)

- OpenStack projects that need to depend on these will reference the git
repo of the project in their tools/pip-requires file. This should take
care of depends for developers. Normal installation depends can be taken
care of by distro packagers as usual.

As best we can tell, this should handle the development case and allow
for better pip installing of code into virtualenv for the developer
workflow without doing screwy things that imply deployment
infrastructure. Other solutions discussed involved multiple modules per
repo (which actually breaks pip -e) and creating our own PyPI that we
upload trunk eggs of all of OpenStack software from and then
reconfiguring install_venv.py to look at that repo. Those are both
kludgy, whereas this actually serves final distro needs as well as
developer needs.

It also helps out with a versioning issue, which was that we were trying
to find a computer-workable approach for dealing with pre-release
versions of nova/glance/keystone that worked for both Ubuntu and for
PyPI - and it turns out that there isn't a good answer. With this
approach, the problem goes away.

Finally, as we're on the cusp of rolling out some integration-test
gating of trunk, it's important that we can also gate all of the
components that are used as a part of that gating. (would suck if the
client lib being used to test broke all of a sudden)

We'd love to get a PPB vote on this approach, and if people consent
begin to implement it. Glance needs to split its client lib out, and
keystone and nova client libs need to get moved to gerrit and the
openstack org.

Thoughts or feedback?

Monty