Open Stack

Monty Taylor wrote:
> We generally do not allow multiple python packages per git repo (that
> is, more than one directory each with its own setup.py) But the thing
> is, if you want a package with its own setup.py, make it its own repo
> with its own lifecycle as well, release it to places like pypi, and then
> consume it in other things. We have done this already with the split of
> client libs from servers and I think we all pretty much get how it
> works. Splitting an additional piece out into an additional repo would
> not  be hard.
> 
> We can do what we need to in gerrit/jenkins. Let's start first with
> deciding theoretically what a perfect world would be, and then we can
> work on discussing how we'll implement that.
> 
> It sounds to me like there is a thing called keystoneclient, a think
> called keystone, and a thing called auth_token (please let's fine a
> better name if we break it out) One of the things we want our of life is
> for auth_token and keystone to both consume keystoneclient. We also may
> want multiple other projects to consume auth_token. Yeah?
> 
> To me that sounds like we want not only a repo for auth_token, but a
> pypi entity that other projects can potentially consume. ne pas?

>From a governance standpoint, that would be considered another "library"
project, but still under Keystone PTL's realm and sharing the same core
team.

http://wiki.openstack.org/Projects

So it technically doesn't need a fancy name (not more than
python-keystoneclient does). Keeping keystone in the name will make it
clearer that it shares PTL/core team with Keystone... So I'd call it
keystone-middleware... even if it's way more boring than Capstone.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack