[Gluster-devel] Global option for nfs-ganesha

[Meghana Madhusudhan]

Hi Niels,

Reply inline.

----- Original Message -----
From: "Niels de Vos" <ndevos at redhat.com>
To: "Meghana Madhusudhan" <mmadhusu at redhat.com>
Cc: gluster-devel at gluster.org, "Krishnan Parthasarathi" <kparthas at redhat.com>
Sent: Thursday, January 22, 2015 2:47:26 AM
Subject: Re: Global option for nfs-ganesha

On Wed, Jan 21, 2015 at 08:51:06AM -0500, Meghana Madhusudhan wrote:
> Hi all,

Hey Meghana,

> We're trying to implement a global option for NFS-Ganesha that'll look
> like this,
> 
> gluster vol set all features.ganesha on
> 
> This is intended to disable gluster-nfs throughout the gluster trusted
> pool, start NFS-Ganesha server and configure HA for NFS-Ganesha.

An important note is that the option should also affect volumes that
get created after setting the option.

Thanks for bringing this up Niels. Yes, that's very important. We need to make sure that attempt to
start gluster-nfs is not done when features.ganesha is set on
the existing volumes.

> A dummy translator has been introduced to manage this global option
> and one more volume level option. 

I understand it like this, please correct me if I'm wrong:

0. somehow this 'ganesha management' translator gets loaded per volume
1. gluster volume set all features.ganesha on
2. the 'ganesha management' translator sees the features.ganesha option
   and then sets nfs.disable for its own volume

Or, should the features.ganesha option cause the loading of the
translator?

Features.ganesha option should cause the loading of the translator,
change in ALL the client volfiles and set nfs.disable for ALL volumes.
When <*all*> is used instead of a volume name, there is no change
in the client volfiles. This is because, volume
set would have acquired a volume level lock and it'd be
wrong to make a change in ALL the client volfiles. 

> When this translator is loaded, there has to be a client volfile
> change on ALL the volumes present in the trusted pool. When *<all>* is
> used instead of a volume name, the volume set infrastructure in
> glusterd doesn't result in any volfile changes.

This suggests that 'gluster volume set all' is already available? I have
not seen it used before, what options does it currently support?

Maybe you can explain why the current function as it is available does
not suit your needs?

It's important that the features.ganesha block is written into
all client volfiles. The current infrastructure doesn't support that.


> As per discussions with the glusterd team, we'd need a cluster-wide
> lock to achieve what we require. 

Well, possibly, I do not know all the details what happens in the
background when a volume option is changes. But it is a change to the
volume options that will not be done often, so, *shrug*?

Taking this from KP's reply,
It is required,

"- if this option is persisted in each of the existing volume's
configuration, apart from being globally persisted.

- to synchronize concurrent operations of the form,
"gluster volume set all <some-global-option> <some-value>, if these
operations use a common global configuration file. "

Thanks,
Meghana