On 12/4/18 5:38 PM, Ken Dreyer wrote: > Hi Niels and Kaleb, > > I'm wondering how we could best build nfs-ganesha's ceph FSALs in CBS. > > Right now, since we'll likely support multiple versions of nfs-ganesha > simultaneously for different versions of Ceph, I'm leaning towards > using a custom "dist tag" like thing in the Release field so we don't > collide with what Kaleb's doing at > http://cbs.centos.org/koji/packageinfo?packageID=98 > > Eventually it would be nice to have a unified nfs-ganesha build shared > between Ceph and Gluster. If we built it in storage7-common-candidate, > we would have to tag gluster and ceph into that, which sounds kinda > messy, because you only get to choose one version of each. It'd be > more manageable to have a separate set of tags and targets just for > nfs-ganesha versions. Like: > > storage7-nfs-ganesha-26-el7 > storage7-nfs-ganesha-27-el7 > ... etc > > But that still leaves the problem of shipping a nfs-ganesha-gluster > sub-package that will not have its runtime deps fulfilled in > http://mirror.centos.org/centos/7/storage/x86_64/ceph-nautilus/ . Vice > versa, we'd have a nfs-ganesha-ceph sub-package that lacks runtime > deps in http://mirror.centos.org/centos/7/storage/x86_64/gluster-5/ I too would like to get to a place where we have a single ganesha package. Gluster's GFAPI guarantees its ABI by using versioned symbols. A Gluster FSAL built against glusterfs-4.1 (or earlier) will work with glusterfs-5's libgfapi.so. And glusterfs-6's. And so on. So we don't build separate ganesha-2.7 packages for both glusterfs-4.1 and glusterfs-5. We build a single ganesha-2.7 package with glusterfs-4.1 and it is tagged into both the glusterfs-4.1 and glusterfs-5 releases. I think it should be achievable. I try and build ganesha with as many FSALs enabled as possible. It's been a while though since I looked at which version of Ceph was in CBS for the Storage SIG. If Ceph doesn't guarantee its ABIs though that's going to make things harder. -- Kaleb