[Gluster-devel] Events API: Adding support for Client Events

[Vijay Bellur]

On 08/23/2016 01:13 PM, Aravinda wrote:
>
> regards
> Aravinda
>
> On Tuesday 23 August 2016 09:32 PM, Pranith Kumar Karampuri wrote:
>>
>>
>> On Tue, Aug 23, 2016 at 9:27 PM, Aravinda <avishwan at redhat.com
>> <mailto:avishwan at redhat.com>> wrote:
>>
>>     Today I discussed about the topic with Rajesh, Avra and Kotresh.
>>     Summary as below
>>
>>     - Instead of exposing eventsd to external world why not expose a
>>     Glusterd RPC for gf_event, Since Glusterd already has logic for
>>     backup volfile server.
>>     - Gluster Clients to Glusterd using RPC, Glusterd will send
>>     message to local eventsd.
>>
>>
>>     Any suggestions for this approach?
>>
>>
>> If I remember correctly this is something we considered before we
>> finalized on exposing eventsd. I think the reason was that this
>> approach takes two hops which we didn't like in the discussion at the
>> time. Did any other parameter change for reconsidering this approach?
> - No extra auth required other than existing glusterd communication
> - Backup volfile server for sending message to other glusterd of server
> if one server is down
> - Events traffic is not heavy two hops may be acceptable(?)
>

Depending on the number of clients connected to a glusterd and the state 
of the cluster, the intensity of eventing traffic might not be 
insignificant. We have come across instances where management operations 
have timed out due to glusterd being overwhelmed with RPC messages. We 
certainly would not want our eventing infrastructure to burden 
glusterd(s) further and worsen the operational state of the cluster. 
Have we considered any throttling mechanism if events are to be routed 
through glusterd?

Thanks,
Vijay