On Wed, Jun 17, 2020 at 10:09 AM Jeff Layton <jlayton(a)redhat.com> wrote:
 (I sent this to a smaller list of folks yesterday, but I think it
 probably warrants wider discussion).
 Recently Varsha added the necessary infrastructure to bring up
 nfs-ganesha via vstart.sh. The current implementation requires that
 ganesha already be installed on the box (usually via distro packaging),
 but that poses a bit of a problem.
 A distro ganesha package will have likely been built vs. a completely
 different version of libcephfs and librados. Even if you build right off
 of ceph master branch, you won't get the benefit of any recent client
 bugfixes when you want to test ganesha. You'd have to build new ganesha
 packages, install them, etc. 
Is it not using stable APIs from those two shared libraries? i.e. QEMU
is compiled and linked against librbd/librados, but I can set
"LD_LIBRARY_PATH" to pull in development versions if needed.
 I think we ought to consider making a nfs-ganesha build an optional
part
 of a ceph build (maybe enable it with cmake -DNFS_GANESHA=ON or
 something).
 It doesn't take very long to build it (typically only a minute or two on
 my box), and we could disable the parts that ceph doesn't care about
 (other FSALs primarily). We could also have vstart just error out when
 you run it with NFS=X on a build that didn't have ganesha enabled.
 OTOH, the potential downside here is that it'll likely add other build-
 time dependencies, and would require some extra cmake or scripting
 wizardry. Nothing insurmountable, but it might represent a maintenance
 burden going forward, particularly for something that's basically only
 going to be used for vstart.
 I'm also not sure how we'd do this in practice. I don't think you can do
 optional submodules, so we might have to look at other methods of
 pulling in the ganesha tree, or just live with it as a submodule that
 only gets used when ganesha is enabled.
 Thoughts?
 --
 Jeff Layton <jlayton(a)redhat.com>
 _______________________________________________
 Dev mailing list -- dev(a)ceph.io
 To unsubscribe send an email to dev-leave(a)ceph.io
 
-- 
Jason