[Gluster-devel] [RFC] Reducing maintenance burden and moving fuse support to an external project

[Jeff Darcy]

> At the moment we have three top-level interfaces to maintain in
> Gluster, these are FUSE, Gluster/NFS and gfapi. If any work is needed
> to support new options, FOPs or other functionalities, we mostly have
> to do the work 3x. Often one of the interfaces gets forgotten

I think the picture's a bit more complicated than that.  When core
features are added, supporting them often requires work in Ganesha
and/or Samba as well as GFAPI.  Indeed, those are often the only things
driving that core work, and the results aren't even accessible via FUSE.
In those cases, the technical underpinnings of our FUSE translator won't
matter at all.  Even when FUSE *is* involved, the work necessary to
update xfuse will still be non-zero.  Adding a feature to GFAPI doesn't
magically add it to every GFAPI-based interface.  We'll still have to do
a lot of work 3x, and I bet we'll still forget to update them all
sometimes.

> Yes, there are definitely a lot of features that we need to add.

That's the key.  While I like the idea of switching to an xglfs-based
solution in principle, I think we need a clearer picture of what work
still needs to be done *before* we can make more concrete plans.  Does
every kind of notify (including that GF_EVENT_AUTH_FAILED hack) work the
same in xglfs as now?  Do graph switches work the same?  What about
performance or memory use?  When we know those answers, and more that
might fall out from running a prototype through our existing regression
tests, then we can weigh that against the improved maintainability of
the newer code.  Until then, we're kind of guessing.