Not all (nor most) Zipper backends are going to be in-tree, but motr wants to be, so we need to find a happy medium. Matt On Wed, Jan 5, 2022 at 6:34 PM Gregory Farnum <gfarnum@xxxxxxxxxx> wrote: > > On Wed, Jan 5, 2022 at 9:39 AM Daniel Gryniewicz <dang@xxxxxxxxxx> wrote: > > > > We are getting ready to merge our first contributed Zipper Store, and > > we'd like to have it build by default in Jenkins, so that we don't > > accidentally break it all the time. We have RPMs, but not DEBs. This > > brought up the question for us: Does Jenkins use both Centos and > > Ubuntu? If so, how does it pick which one it's using? Is there some > > way we can limit RGW-related builds to Centos, or do we need to get debs > > from our contributors? > > I think I've missed something about Zipper. Why does it depend > directly on the distribution choice? > > Okay, guess this is about PR https://github.com/ceph/ceph/pull/44379 > > I built a couple different CephFS plugins for other projects back in > the day and am trying to remember why this wasn't an issue for those. > Hadoop just decided they weren't taking any more external FS plugins > around then, so I guess they never even tried to build it. My guess is > Hypertable's testing was also pretty limited at that point. For > ourselves, we just pulled down a given Hadoop release to do our builds > and the patchy automated testing that happened. > > Ceph distributes upstream packages for Ubuntu and CentOS, and there's > no plan to change that. In my opinion, anything which is part of Ceph > (which it needs to be, if it's getting tested in the Ceph > infrastructure) needs to be built and buildable for both those classes > of packaging. > > That said, if the Zipper architecture requires modifying Ceph code to > run external plugins, that sounds like a world of hurt. I haven't seen > any of the implementation details before so this certainly isn't a > good time for the MOTR guys, but I'd encourage the RWG team to think > about alternative integration models there if you anticipate more > third-party backends. Something that requires dropping a shared > library into a folder and detects them as options and blindly passes > through configs based on a defined naming scheme, instead of needing > to maintain an in-tree if-else tree and config definitions, is a lot > more scalable/maintainable. Plus it keeps a good interface boundary > for things like testing concerns... > -Greg > > > > > > Thanks, > > Daniel > > > > _______________________________________________ > > Dev mailing list -- dev@xxxxxxx > > To unsubscribe send an email to dev-leave@xxxxxxx > > > > _______________________________________________ > Dev mailing list -- dev@xxxxxxx > To unsubscribe send an email to dev-leave@xxxxxxx > -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-821-5101 fax. 734-769-8938 cel. 734-216-5309 _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
