openstack team mailing list archive

[Maru Newby <mnewby@xxxxxxxxxxxx>]

Hi John,

On 2012-04-11, at 8:03 PM, John Dickinson wrote:

> I do not think that these pieces of middleware belong in the core swift repo.

Understood.  

> 1) Including them in swift would require swift to depend on keystone for full testing.

As I mentioned in my initial email, the modules in question depend on Keystone only at the protocol level, and the unit tests run without any dependence on Keystone.  I'm presuming that by 'full testing' you mean the currently non-existent functional tests?

> 2) (When the middleware was created) Keystone's API was in a state of constant flux. Keystone has changed quite a bit since then, so this may not be the case anymore.

As of the essex release, the API and protocol used to communicate identity via the environment can be considered more or less stable. 

> 3) Swift does not require Keystone to run (and in fact many production environments don't use keystone at all). [1]

Definitely a good point.

> 4) We have previously removed auth systems from swift's core code in order to simplify the codebase and allow separate dev cycles. All that is included now is the most basic auth system required for dev work, stand-alone tests, and POC deployments.
> Our thought thus far has been that auth systems providing auth for swift have the responsibility to maintain their integration code. It's not swift's responsibility to manage and maintain code for every auth system that wants to provide an auth mechanism for swift.

I understand - swift core doesn't want to take on responsibility for integrating with different auth systems.

> That being said, there has been quite a bit of recent conversation about the concept of *-contrib areas for each project that include optional add-ons/extensions/plugins/etc or alternative APIs for each project. I expect these conversations to continue next week in person at the summit. One option is for the swift keystone middleware to be a part of such a contrib area.
> 
> It sounds like there are good reasons for both projects to not want to include these pieces of middleware in their respective core repos. Perhaps a contrib area can be a compromise, but that does not answer who is responsible for it (ie who maintains the code?). I think that's a separate, but related, question.

+1 for allowing non-core functionality to be included via a 'contrib'-rooted package rather than having to reside outside the repo it targets.

Regardless of whether it is included as 'contrib' or not, would would you have any interest in my factoring out common functionality from tempauth/swauth and making it available for reuse?  

From my understanding, a swift auth mechanism has 3 parts - authentication (authn), token authentication (token_authn), and authorization (authz).  Both of the main implementations (tempauth and swauth) implement all 3 parts independently, though the only thing that differs between them is the authn backend.  The swift_auth middleware from Keystone similarly duplicates the authz functionality of tempauth and swauth.  If the common stuff could be extracted and made available as library modules or base classes, the cost of maintaining any given auth mechanism would be greatly reduced, and creating a new mechanism would be that much easier.

Please let me know your thoughts.

Cheers,


Maru