openstack team mailing list archive

[Monty Taylor <mordred@xxxxxxxxxxxx>]

On 11/07/2011 11:29 AM, John Dickinson wrote:
> In general, I support the idea of good, supported client libraries. I
> have a few questions about this particular proposal.

Good questions, as always. ...

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

I'm personally a little torn on this, but in a slightly different
direction than the thing you're asking here. I think that if we keep the
current pattern of python-*client, then yes, I feel pretty strongly that
every core project (or every generic service for which we have a
reference core project) should have a corresponding client library package.

However - I would also be on board with coalescing them into a single
"python-openstackclient" library which knows how to talk all of the
openstack protocols.

In any case - if we're not shipping client utils, I'm pretty sure we're
failing at something.

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

Well, it would be effectively promoting several existing projects which
are managed in a few different places (rackspace, 4P, etc) to being more
"official" things that live in the OpenStack gerrit and are replicated
to repos in the openstack github org. I have the physical ability to
just do that - but it kind of felt like something that should get buy in
from someone officially.

> 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).

I guess I'm arguing that proper client libraries are an essential part
of a release. If there isn't much to be done in them, then release day
will be really easy. :) (also, the other projects are adding API
features like gangbusters at the moment, so I think the client libs will
be under active dev at least until those settle down.

(speaking of - should we grab the rackspace swift bindings and make a
python-swiftclient out of it?)

On the other hand, we could keep it as it is for the other projects and
allow the PTL to decide. I'd be surprised if folks chose different
cycles for the client libs - but of the things I care about personally,
this is certainly one of the least.

> 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)?

Currently they are different packages - Ubuntu has a python-novaclient
package, for instance. Ultimately that's up to Ubuntu/Fedora/whoever...
but I certainly imagine that any packaging that's produced of openstack
would want to include the client libs/utils.

Thanks!
Monty

> --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
>