On Wed, Jun 17, 2020 at 10:09 AM Jeff Layton <jlayton@xxxxxxxxxx> 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@xxxxxxxxxx> > _______________________________________________ > Dev mailing list -- dev@xxxxxxx > To unsubscribe send an email to dev-leave@xxxxxxx > -- Jason _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
