On Mon, Aug 19, 2013 at 1:55 PM, Roald van Loon <roaldvanloon@xxxxxxxxx> wrote: > Hi Yehuda, > > Thanks for the comments. > > Yeah, I created the wip-rgw-plugin to get a feeling of how it would > look like. It's probably better to see it as a sandbox, but it already > clearly shows some of the flaws that you point out. > > It doesn't need to link into the rgw binary of course, but yes the > dl'd .so still expects the (although unexported) symbols to be there. > > I personally am a *big* fan of a clean internal API and dynamically > loadable libraries, especially because I want the librgw to have this > feature in the future. For instance, I'd really like a nginx module > one day which links to librgw but not all of the APIs or all of the > authentication mechanism. The nginx module might want to load/unload > specific plugins when it needs to. Same goes for a python extension. > An import rgw should not always also be an import rgw.s3 etc. I'd > really like these features and mostly I'd really like these features > to be slim and not 50+ MB plus.... Right. However, that doesn't really mean we necessarily need to have tight internal api. It might mean that we'd need to define a different set of apis that will encapsulate these use cases. E.g., rgw data access api, direct user management, etc. By the way, the biggest problem with direct nginx integration is that nginx is event driven, whereas internally the gateway is synchronous (albeit threaded). > > I agree it's a lot of work (wouldn't call it noble though), but I > don't see that as an argument to not do it. However, I also agree that > the blueprint/internal API should be extended much more. That's why I > asked for comments to begin with :-) Well, practically I'd like to have such work doing baby steps, rather than swiping changes. Such changes have higher chances of getting completed and eventually merged upstream. That's why I prefer the current model of directly linking the plugins (whether statically or dynamically), with (relatively) minor internal adjustments. > > I'll start thinking about a design for an internal API but I'll > definitely need some help with that. I'm not a fulltime Ceph developer > :-) Maybe start with thinking about the use cases, and then figure what kind of api that would be. As I said, I'm not sure that an internal api is the way to go, but rather exposing some lower level functionality externally. The big difference is that with the former we tie in the internal architecture, while the latter hides the [gory] details. > > Roald > > > > > On Mon, Aug 19, 2013 at 10:05 PM, Yehuda Sadeh <yehuda@xxxxxxxxxxx> wrote: >> On Mon, Aug 19, 2013 at 5:34 AM, Roald van Loon <roaldvanloon@xxxxxxxxx> 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 <yehuda@xxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
