Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-17601

explore the alternative way to replace using multicast for server auto discovery

    Details

    • Type: Story
    • Status: Done
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: SUIT
    • Labels:
    • Story Points:
      4
    • Sprint:
      SUIT Sprint 2019-02
    • Team:
      Science User Interface

      Description

      After discussion with Google experts, they suggested us to look into an alternative way for server discovery to replace the needs of multicast. (Multicast does not work in GKE if the Firefly server pods are on different nodes). 

      http://www.smartjava.org/content/service-discovery-docker-and-consul-part-1/

       

      This will involve modifying Firefly to read the configuration at build time to decide on the library to use for service auto discovery. When it is in k8s environment, other software package may need to be installed. We need to document this in SUIT deployment procedure DM-16670

        Attachments

          Issue Links

            Activity

            Hide
            loi Loi Ly added a comment -

            At the discussion, we talked about replacing the current multicast based discovery mechanism with something else.  Ideas include etcd, redis, and consul.  Upon review, I think the most straight-forward approach with the least learning curve is redis.  The purpose of this external service is to store the information of active firefly instances.  Nothing fancy.

            We will deploy one redis container as a known service for which multiple firefly containers will register to.
            This requires adding redis to our kubernetes deployment, which is simple.
            The bulk of the work is to implement the new discovery mechanism and testing it.  Because this involves integrating with third-party interfaces, there may be unforeseeable obstacles.

            My best guess is around 2 weeks.

             

            Show
            loi Loi Ly added a comment - At the discussion, we talked about replacing the current multicast based discovery mechanism with something else.  Ideas include etcd, redis, and consul.  Upon review, I think the most straight-forward approach with the least learning curve is redis.  The purpose of this external service is to store the information of active firefly instances.  Nothing fancy. We will deploy one redis container as a known service for which multiple firefly containers will register to. This requires adding redis to our kubernetes deployment, which is simple. The bulk of the work is to implement the new discovery mechanism and testing it.  Because this involves integrating with third-party interfaces, there may be unforeseeable obstacles. My best guess is around 2 weeks.  
            Hide
            xiuqin Xiuqin Wu [X] (Inactive) added a comment -

            Developer has done preliminary study and proposed a preferred solution.

            Show
            xiuqin Xiuqin Wu [X] (Inactive) added a comment - Developer has done preliminary study and proposed a preferred solution.
            Hide
            xiuqin Xiuqin Wu [X] (Inactive) added a comment -

            Loi Ly Could you provide two conceptual diagrams for both redis and consul? The LSP lead would like to understand the design before we start implementing the solution. 

            Show
            xiuqin Xiuqin Wu [X] (Inactive) added a comment - Loi Ly Could you provide two conceptual diagrams for both redis and consul? The LSP lead would like to understand the design before we start implementing the solution. 
            Hide
            loi Loi Ly added a comment -

            Attached is the diagrams requested.  There's not much there, so feel free to ask questions if you have any.  I'll do my best to answer them.
            Firefly cache auto-discovery conceptual design - Loi Ly - Confluence.pdf.pdf

            Show
            loi Loi Ly added a comment - Attached is the diagrams requested.  There's not much there, so feel free to ask questions if you have any.  I'll do my best to answer them. Firefly cache auto-discovery conceptual design - Loi Ly - Confluence.pdf.pdf
            Hide
            xiuqin Xiuqin Wu [X] (Inactive) added a comment -

            The conceptual design diagrams are attached for consul and redis. Redis is recommended for its simplicity and light weight container. 

            Show
            xiuqin Xiuqin Wu [X] (Inactive) added a comment - The conceptual design diagrams are attached for consul and redis. Redis is recommended for its simplicity and light weight container. 

              People

              • Assignee:
                loi Loi Ly
                Reporter:
                xiuqin Xiuqin Wu [X] (Inactive)
                Reviewers:
                Emmanuel Joliet, Xiuqin Wu [X] (Inactive)
                Watchers:
                Emmanuel Joliet, Loi Ly, Xiuqin Wu [X] (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Summary Panel