On Tue, Aug 20, 2013 at 4:49 PM, Yehuda Sadeh <yehuda@xxxxxxxxxxx> wrote: > I was referring to your work at wip-rgw-plugin, where the plugin code > itself still needs to rely on the rgw utility code. Right. So we can agree on ditching the dynamic loading thing and clean internal API (for now), but at least start separating code into "plugins" like this? > That's not quite a hard dependency. At the moment it's like that, as > we made a decision to use the S3 auth for the admin utilities. > Switching to a different auth system (atm) would require defining a > new auth class and inheriting from it instead. It's not very flexible, > but it's not very intrusive. > I'd certainly be interested in removing this inheritance relationship > and switch to a different pipeline model. I don't know if you looked at it in detail, but for the wip-rgw-plugin work I created a RGWAuthManager / RGWAuthPipeline relation to seggregate authentication specific stuff from the REST handlers. Is that in general a model you like to see discussed in more detail? If so, it would probably be wise to start a separate blueprint for it. > As I said, I don't see it as such. We do use it all over the place, > but the same way you could just switch these to use > RGWHandler_Auth_Swift and it should work (give or take a few tweaks). IMHO, REST handlers should leave authentication/authorization/accounting specific tasks to a separate component (like the aforementioned pipelining system, and maybe integrate that with current RGWUser related code), although this will likely never be purely abstracted (at least for authentication). This just makes the whole system more modular (albeit it just a bit). But for now I propose to implement a small "plugin" system where plugins are still linked into the rgw core (but code wise as much separated as possible), and keep the auth stuff for later. Roald -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
