openstack team mailing list archive

[Jan Drake <jan_drake@xxxxxxxxxxx>]

+1




On Nov 7, 2011, at 10:53 AM, Monty Taylor <mordred@xxxxxxxxxxxx> 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
>