[openstack-dev] Keystone auth_token middleware
Thierry Carrez
thierry at openstack.org
Tue Sep 25 10:13:53 UTC 2012
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
More information about the OpenStack-dev
mailing list