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