On Tue, Aug 23, 2016 at 9:27 PM, Aravinda <[email protected]> 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? > While this implementation might be easy, but I don't think from an architecture and design perspective this stands correct (initially I actually thought about it too). Consumers of gf_event () should be able to find a way to directly communicate to the eventsd and for that establishment GlusterD can be queried for the first time, but not every time. Kaushal - your thoughts? > > regards > Aravinda > > > On Thursday 04 August 2016 11:04 AM, Aravinda wrote: > >> >> 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 <[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]? >>> >> 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/managemen >>> t_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
