[Gluster-devel] gfapi: add function to set client-pid

[Niels de Vos]

On Tue, Mar 12, 2019 at 03:00:27PM +0530, Ravishankar N wrote:
> Hello,
> 
> I'm planning to expose setting client-pid for gfapi clients via a new api,
> something like `glfs_set_client_pid (fs, pid)`.
> The functionality already exists for fuse mounts via the --client-pid=$PID
> option, where the value is captured in
> glusterfs_ctx_t->cmd_args->client_pid.
> 
> Background:
> 
> If the glusterfs eventing framework is enabled, AFR sends child-up/child
> down events (via the gf_event() call) in the notify code path whenever there
> is a connect/disconnect at AFR level. While this is okay for normal client
> processes, it does not make much sense if the event is coming from say
> glfsheal, which is a gfapi based program (having the AFR xlator) that is
> invoked when you run the heal info set of commands. Many applications
> periodically run heal info to monitor the heals and display it on the
> dashboard (like tendryl), leading to a flood of child up/ down messages to
> the application monitoring these events.
> 
> We need to add a unique key=value to all such gf_event() calls in AFR, based
> on which the consumer of the events can decide to ignore them if needed.
> This key-value can be client-pid=$PID, where PID can be
> GF_CLIENT_PID_SELF_HEALD for selfheal daemon, GF_CLIENT_PID_GLFS_HEAL for
> glfsheal etc (these values are already defined in the code). This is why we
> need a way to set the client-pid for gfapi clients as well.
> 
> Another approach would be to add an xlator option (say 'client-name')
> specific to AFR  and use that as the key-value pair but it seems to be an
> overkill to do that just for the sake of eventing purposes. Besides, the pid
> approach can also be extended to other gluster processes like rebalance, shd
> and other daemons where AFR is loaded but AFR child-up/down events from it
> are not of any particular interest.These daemons will now have to be spawned
> by glusterd with the --client-pid option.

Sounds good to me. This probably should be a function that is not
available to all gfapi consumers, so please use api/src/glfs-internal.h
for that. With clear documentation as written in the email, it should be
obvious that only Gluster internal processes may use it.

Adding the integration mailinglist on CC, as that is where all
discussions around gfapi should be archived.

Thanks,
Niels