On Mon, Aug 19, 2013 at 5:34 AM, Roald van Loon <[email protected]> wrote: > Hi, > > I started out by defining the plugin system a bit more > (http://wiki.ceph.com/01Planning/02Blueprints/Emperor/rgw:_plugin_architecture). > I'd really appreciate any comments. > > On Wed, Aug 14, 2013 at 8:40 PM, Yehuda Sadeh <[email protected]> wrote: >>> - "AUTH" (Authentication backends): Rados/internal, Keystone >> >> That's probably the best place to start. > > I also started working on an "auth" type of plugin for all Keystone > support based on the plugin system currently described in the > blueprint (it's an extremely simple and flexible system and IMHO a > good way to start). Contrary to the "plugin system", the auth plugin > itself will move a lot of code around and will therefore have a much > greater impact. So it's probably better to separate these projects > completely. If we can reach consensus about the way the first version > of the plugin system should look like, I will separate these commits > into different branches so we can merge it one step at a time. >
I went over the blueprint, and partially through the code (wip-rgw-plugin). I'm not completely sure about the plugin <-> core interface that you had in mind. At the moment there's no clean interface, and it just links directly. For example, the keystone plugin needs to call rgw_store_user_info(), the KeystoneClient needs to inherit from RGWHTTPClient, etc. So on one hand we now move this code into external module, but otoh, it still need to link into the monolithic rgw core. Having a clean internal api might be a noble idea, but I'm not sure it's very practical (which is in line with what's there now). Having a linux-kernel like module model makes sense here. The modules/plugins will need to be compiled against the specific version in order for them to be able to load successfully. Also, I'm not sure that we need to bother with dynamic loading. Yehuda -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
