Hi Sage, Please find the initial implementation of objects store factory (initial cut) at https://github.com/varadakari/ceph/commit/9d5fe2fecf38ba106c7c7b7a3ede4f189ec7e1c8 This is still work in progress branch. Right now I am facing Lttng issues, LTTng-UST: Error (-17) while registering tracepoint probe. Duplicate registration of tracepoint probes having the same name is not allowed. Might be an issue with libcommon inclusion. Trying resolving the issue now. Seems I need to make libcommon also as a shared object to avoid the duplicates, static linking is a problem here. Any suggestions or comments on this problem? I have commented out test binary (ceph_test_keyvaluedb_atomicity) compilation, due to unresolved symbols for g_ceph_context and g_conf. Not able to fix/workaround the problem so far. Can you please review if this is what in your mind for the factory implementation? We can extend this implementation to messenger and different backend of the OSD. Will make those incremental once the base framework is approved. Thanks, Varada -----Original Message----- From: Sage Weil [mailto:sage@xxxxxxxxxxxx] Sent: Tuesday, May 12, 2015 5:11 AM To: Varada Kari Cc: Loic Dachary; Matt W. Benjamin; ceph-devel Subject: RE: loadable objectstore Hi Varada, Any progress on this? Thanks! sage On Sat, 11 Apr 2015, Varada Kari wrote: > Thanks Sage and Loic. Will add the missing pieces and integrate the object factory and plugin changes. > > Varada > > -----Original Message----- > From: Sage Weil [mailto:sage@xxxxxxxxxxxx] > Sent: Saturday, April 11, 2015 9:19 PM > To: Loic Dachary > Cc: Varada Kari; Matt W. Benjamin; ceph-devel > Subject: Re: loadable objectstore > > On Sat, 11 Apr 2015, Loic Dachary wrote: > > Hi Sage, > > > > It looks like common/PluginRegistry.{h,cc} are missing from > > 18ad8df1094db52c839dc6b2dc689fc882230acb > > whoops pushed! :) > > sage > > > > > Cheers > > > > On 11/04/2015 16:51, Sage Weil wrote: > > > On Sat, 11 Apr 2015, Varada Kari wrote: > > >> Hi Matt/ Sage, > > >> > > >> Thanks for sharing the pull request. Will work on the items what > > >> sage was mentioning in the comments along with the items in the tracker. > > > > > > I pushed a wip-plugin branch with the pattern I had in mind... > > > does this make sense? It's only compile tested, and still needs > > > preload() methods implemented so that long-running daemons (or > > > perhaps others?) can preload it all at once. > > > > > > Ideally we would replace ErasurePluginRegistry with this too, > > > which means the naming of the .so's needs to be a bit more > > > flexible as the EC plugin scheme is something like > > > /usr/lib/ceph/erasure-code/libec_$name.so (not a strict function > > > of type and name). Or actually, we can just rename the EC .so's > > > when this goes in? Since they're explicitly incompatible between > > > versions there is no reason the names need to remain consistent... > > > > > > sage > > > > > >> > > >> Varada > > >> > > >> -----Original Message----- > > >> From: Sage Weil [mailto:sage@xxxxxxxxxxxx] > > >> Sent: Saturday, April 11, 2015 4:16 AM > > >> To: Matt W. Benjamin > > >> Cc: Varada Kari; ceph-devel > > >> Subject: Re: loadable objectstore > > >> > > >> On Fri, 10 Apr 2015, Matt W. Benjamin wrote: > > >>> Hi Varada, > > >>> > > >>> I pushed branch hammer-osfactory to > > >>> https://github.com/linuxbox2/ceph.git > > >>> > > >>> It can at least provide a starting point for discussion, if not > > >>> a jumping off point; I do think it's basically what Sage described. > > >> > > >> I made a few comments on the pull request. I think a factory class is the way to go, but we should be able to make the plugin loading part generic and not interface specific at all... > > >> > > >> sage > > >> > > >>> > > >>> I was able to update the CMake build system to build the tree, I > > >>> haven't attempted Autotools. :( > > >>> > > >>> Regards, > > >>> > > >>> Matt > > >>> > > >>> -- > > >>> Matt Benjamin > > >>> CohortFS, LLC. > > >>> 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 > > >>> > > >>> http://cohortfs.com > > >>> > > >>> tel. 734-761-4689 > > >>> fax. 734-769-8938 > > >>> cel. 734-216-5309 > > >>> -- > > >>> 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 > > >>> > > >>> > > >> > > >> ________________________________ > > >> > > >> PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies). > > >> > > >> -- > > >> 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 > > >> > > >> > > > -- > > > 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 > > > > > > > -- > > Loïc Dachary, Artisan Logiciel Libre > > > > > -- > 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 > > -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
