On 12/03/19 4:20 PM, Niels de Vos wrote:
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.
Hi Niels,
The gfapi patch [1] is awaiting your review.
Thanks,
Ravi
[1] https://review.gluster.org/#/c/glusterfs/+/22368/
Thanks,
Niels
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-devel
