[Gluster-devel] xlator option setting in gfapi

[Poornima Gurusiddaiah]

Hi,

Reply inline

Regards,
Poornima

----- Original Message -----
> From: "Raghavendra Gowdappa" <rgowdapp at redhat.com>
> To: "Raghavendra Talur" <rtalur at redhat.com>
> Cc: "Poornima Gurusiddaiah" <pgurusid at redhat.com>, "Gluster Devel" <gluster-devel at gluster.org>, "Jeff Cody"
> <jcody at redhat.com>, "Rajesh Joseph" <rjoseph at redhat.com>
> Sent: Monday, May 9, 2016 12:17:25 PM
> Subject: Re: xlator option setting in gfapi
> 
> 
> 
> ----- Original Message -----
> > From: "Raghavendra Talur" <rtalur at redhat.com>
> > To: "Raghavendra Gowdappa" <rgowdapp at redhat.com>
> > Cc: "Poornima Gurusiddaiah" <pgurusid at redhat.com>, "Gluster Devel"
> > <gluster-devel at gluster.org>, "Jeff Cody"
> > <jcody at redhat.com>, "Rajesh Joseph" <rjoseph at redhat.com>
> > Sent: Monday, May 9, 2016 11:57:44 AM
> > Subject: Re: xlator option setting in gfapi
> > 
> > On Mon, May 9, 2016 at 8:45 AM, Raghavendra Gowdappa <rgowdapp at redhat.com>
> > wrote:
> > 
> > > Hi Poornima/Raghavendra,
> > >
> > > This mail is an initiation of a thread to discuss how to make xlator
> > > options setting in gfapi synchronous (so, that caller will know the
> > > result)
> > > or providing a cbk to let the application know about the status.
> > >
> > > My very naive attempt of code-reading showed me that
> > > pub_glfs_set_xlator_option just adds the option to
> > > cmd_args.xlator_options.
> > > Can you please explain how/when these values are communicated to glusterd
> > > to change volfile? From there we can carry forward the conversation.
> > >
> > >
> > Raghavendra,
> > 
> > glfs_set_xlator_option is equivalent to --xlator-option of mount.glusterfs
> > of FUSE. This feature is not intended to apply the setting to the volume
> > permanently, rather it is specific to the mount and only valid for its
> > lifetime.
> > The current architecture of Gluster graph takes these options only in
> > cmd_args and then these values are given preference over whatever comes in
> > volfile from Glusterd. In essence, these settings can be used to override
> > the volume settings for a particular mount.
> 
> For this use case, even a way to modify the options for a single mount is
> fine. But the problem is, how do I know whether the option I set has taken
> effect? Is checking return value of pug_glfs_set_xlator_option is sufficient
> (seems unlikely as I don't see any xlators being involved here)? Can you
> explain the mechanism involved here (as in how this option is propagated to
> relevant xlator - do we call reconfigure with new set of option dict etc)?
> 


This is what happens when glfs_set_xlator_option is called:
- It updates ctx->cmd_args->xlator_options
- gf_add_cmdline_options (during glusterfs_graph_prepare.. pub_glfs_init) 
  adds it to xl->options
- glusterfs_graph_unknown_options (during glusterfs_graph_activate.. pub_glfs_init) 
  checks if the options in xl->options are present or not. If the option is not present
  it just logs a warning message. These options are treated as command line args.

To report the option setting as a failure, at the least we can fail glfs_init().
Would that be an acceptable solution? This change will also affect bricks, fuse mount
and other gluster processes.

> > 
> > If the requirement is to set a volume wide option then glusterd or one of
> > the REST interfaces for Glusterd should be used.
> > 
> > I will also reply to the other thread with possible methods on overcoming
> > the problem with write-behind and qemu.
> > 
> > Thanks,
> > Raghavendra Talur
> > 
> > 
> > > regards,
> > > Raghavendra
> > >
> > 
>