On Wednesday 3 August 2016, Vijay Bellur <[email protected]> wrote: > On 08/02/2016 11:24 AM, Pranith Kumar Karampuri wrote: > >> >> >> On Tue, Aug 2, 2016 at 8:21 PM, Vijay Bellur <[email protected] >> <mailto:[email protected]>> 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]?
I think this token is generated once and persisted. So we really dont need to regenerate it. > > Thanks, > Vijay > > [1] > http://review.gluster.org/#/c/13214/6/under_review/management_rest_api.md > _______________________________________________ > Gluster-devel mailing list > [email protected] > http://www.gluster.org/mailman/listinfo/gluster-devel > -- --Atin
_______________________________________________ Gluster-devel mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-devel
