Hi Niels, Reply inline. ----- Original Message ----- From: "Niels de Vos" <ndevos@xxxxxxxxxx> To: "Meghana Madhusudhan" <mmadhusu@xxxxxxxxxx> Cc: gluster-devel@xxxxxxxxxxx, "Krishnan Parthasarathi" <kparthas@xxxxxxxxxx> 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 _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel