[openstack-dev] [openstack-common] Add auth_token.py from keystone middleware to openstack-common

heut2008 heut2008 at gmail.com
Sun Aug 19 01:54:10 UTC 2012


2012/8/19 Michael Basnight <mbasnight at gmail.com>:
> On Aug 18, 2012, at 3:04 PM, Joseph Heck <heckj at mac.com> wrote:
>
>> Hi Yaguang,
>>
>> I agree that it looks like a close fit for pushing into openstack-common, but I don't have a solid sense of what the boundary is between stuff that's somewhat common and stuff that's project specific. auth_token is in one of those grey areas - it's used by glance, quantum, nova (and keystone), but not swift - swift extended that basic setup to include some additional context and such detail specific to swift. That auth-token-middleware-for-swift code is now in the swift repository (https://github.com/openstack/swift/blob/master/swift/common/middleware/keystoneauth.py)
>>
>> The other part of this is how we do updates - right now a change to Keystone (such as adding PKI support for signed tokens) means updating in a single location (keystone), where if we moved it to OpenStack common, we'd need to update it in more than one location. If it were really locked down and not changing, then I think maybe it would make sense to shift in there, but right now (especially with advancements in PKI/signed tokens) and looking forward to the V3 API set, I don't know that it makes as much sense. My intuition is telling me that it's not sufficiently unchanging and "common" enough to move into common, although getting it there is actually something of a goal.
>>
>> Mark - how and where have you been drawing the line on what and when to shift code into OpenStack common?

I hope this can be done before  folsom-rc1,at that time  when it is
'common' enough,and keystone has
the V3 API ready. so deployment of openstack can be a little simple.
>>
>> - joe
>
> I also recently mentioned the need to update the middleware for common caching in another thread, using beaker. Maybe we can split it out of keystone into its own project instead of putting it in common? But I'll need to pull in some caching stuff that I'll be prop'ing in to common anyway. I think we need a decision here one way or another for the long term.
>
> Side note: I'd prefer to not install all of keystone to get this one module, no matter where it is. But then again, moving this stuff all around is quite annoying to installers ;)
>
> Sent from my digital shackles.
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list