Open Stack

On Sat, 2012-08-18 at 13:04 -0700, Joseph Heck 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?

Not sure how I missed this thread, sorry :(

As I said, anything which would otherwise be copied and pasted between
projects makes sense in openstack-common.

We used to copy auth_token between the projects, but we don't do that
anymore so ... that sounds like there's no need to move it to
openstack-common.

However, is keystone providing (and committed to continuing to provide)
a stable auth_token API to the projects that require it?

Could a situation arise where we make a change to auth_token which
breaks older versions of the projects which require it? If so, then it's
not a good idea for projects to depend on the version supplied by
keystone. Think about the situation where you may want newer keystone
installed on a system, but e.g. older Nova.

So, there are a few options:

  1) auth_token is a stable API, continue to have keystone provide it

  2) auth_token is a stable API, release it as a library in the 
     openstack-common family e.g. oslo-auth-token

  3) auth_token is an unstable API, add it to openstack-common's 
     incubation area and have projects sync a copy of it from there

Cheers,
Mark.