Hi Jeff,
Thanks for writing this up. A few comments in-line:
On Thu, Jan 3, 2019 at 11:05 AM Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> [...]
> My thinking was that we'd probably want to create a new mgr module for
> that, and could wire it up to the command line with something like:
>
> $ ceph nfsexport create --id=100 \
> --pool=mypool \
> --namespace=mynamespace \
I view these three options above as required so I'm wondering if it
should just be either a single positional argument or required option.
Then it would just be formatted as the rados url:
rados:://pool/namespace/100
I'd also suggest reversing the object names (if it's not too late for
that) so it sorts better. Objects could be named "100/{conf,exports}".
To be clear, the purpose of this command is solely to setup the RADOS
objects storing the conf/exports for the Ganesha cluster?
> [...]
> From there, we'd need to also be able to "link" and "unlink" these
> export objects into the config files for each daemon. So if I have a
> cluster of 2 servers with nodeids "a" and "b":
>
> $ ceph nfsexport link --pool=mypool \
> --namespace=mynamespace \
> --id=100 \
> --node=a \
> --node=b
>
> ...with a corresponding "unlink" command. That would append objects
> called "conf-a" and "conf-b" with this line:
I got lost here. Assuming we're starting two Ganesha servers for a
single cluster (active=2), wouldn't they have the same export block
(i.e. export-100)? And, wouldn't that export block already be "linked"
into the config (conf-100)?
(You've spoken in the past about chaining export blocks too but I'm
not convinced we want that.)
> %url rados://mypool/mynamespace/export-100
>
> ...and then call into the orchestrator to send a SIGHUP to the daemons
> to make them pick up the new configs. We might also want to sanity check
> whether any conf-* files are still linked to the export-* files before
> removing those objects.
--
Patrick Donnelly
