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
