Re: Events API: Adding support for Client Events

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Tue, Aug 23, 2016 at 9:27 PM, Aravinda <avishwan@xxxxxxxxxx> 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 <vbellur@xxxxxxxxxx
<mailto:vbellur@xxxxxxxxxx>> 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


_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel



--

--Atin
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel

[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux