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

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

    XMLWordPrintable

Details

    • Story
    • Status: Done
    • Resolution: Done
    • None
    • SUIT
    • 4
    • SUIT Sprint 2019-02
    • 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

            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.

             

            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.  

            Developer has done preliminary study and proposed a preferred solution.

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

            loi 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. 

            xiuqin Xiuqin Wu [X] (Inactive) added a comment - loi 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. 
            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

            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

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

            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

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

              Dates

                Created:
                Updated:
                Resolved:

                Jenkins

                  No builds found.