[Gluster-devel] Notifications (was Re: GF_PARENT_DOWN on SIGKILL)

[Xavier Hernandez]

Hi Jeff,

On 22/07/16 16:14, Jeff Darcy wrote:
>> I don't think we need any list traversal because notify sends it down
>> the graph.
>
> Good point.  I think we need to change that, BTW.  Relying on
> translators to propagate notifications has proven very fragile, as many
> of those events are overloaded to mean very different things to
> different translators (e.g. just being up vs. having quorum) with
> different rules for when they should or should not be propagated.  Going
> forward, I think we can save ourselves a lot of headaches by treating
> notification as an infrastructure responsibility, and changing
> translators to use something else (e.g. IPC fops or upcalls) for their
> internal needs.

I partially agree. I think gluster core should have more control about 
event propagation, however some events, as they are currently used, need 
to be controlled by the xlator in some way.

For example GF_EVENT_CHILD_UP cannot be immediately sent once the xlator 
itself has been completely initialized because this would mean that 
upper xlators could start sending requests. In the specific case of ec, 
this is not good, because with a single child up, the volume is 
completely inoperable. On the other side, waiting for all subvolumes to 
be up (or down) is a waste of time if there's some problem because ec 
can begin working with less bricks.

Maybe the infrastructure should include some way to receive specific 
events from the xlatoes and use them to propagate events between xlators 
when appropriate. This way the xlator is not responsible to propagate 
any event, but to maintain informed the gluster core about its current 
state.

Xavi

>
> But that's a different issue.  For now, just pushing one PARENT_DOWN
> to the top of the graph should suffice.
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>