On Tue, Aug 23, 2016 at 9:27 PM, Aravinda <avish...@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? > > 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 <vbel...@redhat.com >>>> <mailto:vbel...@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/managemen >>> t_rest_api.md >>> >> >> > -- Pranith
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel