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

[Aravinda]

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(?)

>
>     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
>                 <vbellur at redhat.com <mailto:vbellur at redhat.com>
>                 <mailto: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
>             <http://review.gluster.org/#/c/13214/6/under_review/management_rest_api.md>
>
>
>
>
>
>
> -- 
> Pranith

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160823/6e26ce89/attachment-0001.html>