[Gluster-devel] Events API: Adding support for Client Events
Aravinda
avishwan at redhat.com
Thu Aug 4 05:34:25 UTC 2016
regards
Aravinda
On 08/03/2016 09:19 PM, Vijay Bellur wrote:
> On 08/02/2016 11:24 AM, Pranith Kumar Karampuri wrote:
>>
>>
>> On Tue, Aug 2, 2016 at 8:21 PM, Vijay Bellur <vbellur at redhat.com
>> <mailto:vbellur at redhat.com>> wrote:
>>
>> On 08/02/2016 07:27 AM, Aravinda wrote:
>>
>> Hi,
>>
>> As many of you aware, Gluster Eventing feature is available in
>> Master.
>> To add support to listen to the Events from GlusterFS Clients
>> following
>> changes are identified
>>
>> - Change in Eventsd to listen to tcp socket instead of Unix
>> domain
>> socket. This enables Client to send message to Eventsd
>> running in
>> Storage node.
>> - On Client connection, share Port and Token details with Xdata
>> - Client gf_event will connect to this port and pushes the
>> event(Includes Token)
>> - Eventsd validates Token, publishes events only if Token is
>> valid.
>>
>>
>> Is there a lifetime/renewal associated with this token? Are there
>> more details on how token management is being done? Sorry if these
>> are repeat questions as I might have missed something along the
>> review trail!
>>
>>
>> At least in the discussion it didn't seem like we needed any new tokens
>> once it is generated. Do you have any usecase?
>>
>
> No specific usecase right now but I am interested in understanding
> more details about token lifecycle management. Are we planning to use
> the same token infrastructure described in Authentication section of [1]?
If we use the same token as in REST API then we can expire the tokens
easily without the overhead of maintaining the token state in node. If
we expire tokens then Clients have to get new tokens once expired. Let
me know if we already have any best practice with glusterd to client
communication.
>
> Thanks,
> Vijay
>
> [1]
> http://review.gluster.org/#/c/13214/6/under_review/management_rest_api.md
More information about the Gluster-devel
mailing list