I do not think that these pieces of middleware belong in the core swift repo.
1) Including them in swift would require swift to depend on keystone for full testing. 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. 3) Swift does not require Keystone to run (and in fact many production environments don't use keystone at all). [1] 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. 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] Likewise Keystone doesn't require swift and many keystone deployments don't use swift at all. --John On Apr 11, 2012, at 4:07 PM, Maru Newby wrote: > The Keystone repo currently contains the following Swift-specific wsgi > middleware modules: > > https://github.com/openstack/keystone/blob/master/keystone/middleware/s3_token.py > https://github.com/openstack/keystone/blob/master/keystone/middleware/swift_auth.py > > Neither module depends directly on Keystone. s3_token calls Keystone through > HTTP, and swift_auth retrieves Keystone identity data from the wsgi > environment. Both modules, however, depend directly on Swift, and this > forces the Keystone test suite to have to install Swift to run successfully. > > Separate from the dependency issue, both middleware modules need to ensure > that Swift-specific authorization requirements are met. It doesn't make > sense for the Keystone project to be responsible for this, since the Swift > team is the final arbiter of how Swift authorization should behave. > > All signs point to the Swift repo being the best place for these modules to > be maintained. Does this seem reasonable, or is there a better alternative? > Please chime in, especially if you are Swift core. > > Cheers, > > > Maru
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
