openstack team mailing list archive

[John Dickinson <me@xxxxxx>]

In general, I support the idea of good, supported client libraries. I have a few questions about this particular proposal.

1) Would a distinct python client (and the associated project) be required for each core openstack project that exposes an API?

2) Why does the PPB need to vote? Actually, what would the PPB be voting on (assuming the answer to #1 is "no")?

3) Why the requirement to have the same release schedule as the paired project? I would expect a client binding to change much less often than the underlying system (as I have seen with the Rackspace-specific swift bindings).

4) Will these libraries also be included in whatever set of packages are built for the openstack projects (eg as part of a *-dev package)?

--John


On Nov 7, 2011, at 12:53 PM, Monty Taylor wrote:

> 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
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

Attachment: smime.p7s
Description: S/MIME cryptographic signature