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

Prepare the Docker Image of Middleware Code

    XMLWordPrintable

    Details

      Description

      This task will prepare the docker image of middleware code.

        Attachments

          Activity

          Hide
          ttsai Te-Wei Tsai added a comment - - edited

          Checked the rpm build and did not see the update of ts_xml. Need to check with Rob and Dave for this. The new build should be "3.10.0-4.3.0.el7". I only saw the "3.10.0_001-3.10.0.el7".

          Added the build version in the Dockerfile.

          Show
          ttsai Te-Wei Tsai added a comment - - edited Checked the rpm build and did not see the update of ts_xml. Need to check with Rob and Dave for this. The new build should be "3.10.0-4.3.0.el7". I only saw the "3.10.0_001-3.10.0.el7". Added the build version in the Dockerfile.
          Hide
          ttsai Te-Wei Tsai added a comment -

          Created the PR for the docker image:

          https://github.com/lsst-ts/ts_Dockerfiles/pull/39

          Send the email to Russel to use the docker image.

          Show
          ttsai Te-Wei Tsai added a comment - Created the PR for the docker image: https://github.com/lsst-ts/ts_Dockerfiles/pull/39 Send the email to Russel to use the docker image.
          Hide
          ttsai Te-Wei Tsai added a comment -

          Prepared the docker image on docker hub:

          https://cloud.docker.com/u/lsstts/repository/docker/lsstts/hex_rot_middleware

          The PR is at:

          https://github.com/lsst-ts/ts_Dockerfiles/pull/39

          I had wrote an email to explain the use of it.

          Please help to check it. Thanks!

          Show
          ttsai Te-Wei Tsai added a comment - Prepared the docker image on docker hub: https://cloud.docker.com/u/lsstts/repository/docker/lsstts/hex_rot_middleware The PR is at: https://github.com/lsst-ts/ts_Dockerfiles/pull/39 I had wrote an email to explain the use of it. Please help to check it. Thanks!
          Hide
          rowen Russell Owen added a comment - - edited

          For the record, these are the steps I used (based on Te-Wei's email):

          • docker pull lsstts/hex_rot_middleware:3.10_4.3
          • docker run -it --rm lsstts/hex_rot_middleware:3.10_4.3
          • # Do the following in the Docker container:
          • git clone -b develop https://github.com/lsst-ts/ts_mt_hexRot_middleware.git
          • cd ts_mt_hexRot_middleware
          • export HEX_ROT_MIDDLEWARE_HOME=$PWD
          • make libyaml
          • make all # builds mainTstClient in bin/
          • cd simulator
          • make all # builds simulator in ../bin
          • cd .. # back to ts_mt_hexRot_middleware
          • ./bin/mainTcsClient tests/testData/defaultTest.yaml
          • # You should see messages including "Starting Middleware Gateway"
          • # Now start a new Terminal session on your computer (not in the Docker container)
          • docker ps # Use the container ID of image you are running in the following command:
          • docker exec -it <container_id> bash
          • # In this new login to your container:
          • cd ts_mt_hexRot_middleware/
          • ./bin/simulator
          • # You should see the middleware start up including a message "Connected to the server"
          • # In your first container session you should see these messages: "rotator command processor ready" and "hexapod command processor ready"

          Te-Wei also explained how to change the IP address but I did not try that.

          Show
          rowen Russell Owen added a comment - - edited For the record, these are the steps I used (based on Te-Wei's email): docker pull lsstts/hex_rot_middleware:3.10_4.3 docker run -it --rm lsstts/hex_rot_middleware:3.10_4.3 # Do the following in the Docker container: git clone -b develop https://github.com/lsst-ts/ts_mt_hexRot_middleware.git cd ts_mt_hexRot_middleware export HEX_ROT_MIDDLEWARE_HOME=$PWD make libyaml make all # builds mainTstClient in bin/ cd simulator make all # builds simulator in ../bin cd .. # back to ts_mt_hexRot_middleware ./bin/mainTcsClient tests/testData/defaultTest.yaml # You should see messages including "Starting Middleware Gateway" # Now start a new Terminal session on your computer (not in the Docker container) docker ps # Use the container ID of image you are running in the following command: docker exec -it <container_id> bash # In this new login to your container: cd ts_mt_hexRot_middleware/ ./bin/simulator # You should see the middleware start up including a message "Connected to the server" # In your first container session you should see these messages: "rotator command processor ready" and "hexapod command processor ready" Te-Wei also explained how to change the IP address but I did not try that.
          Hide
          rowen Russell Owen added a comment -

          The changes on github look reasonable to me (though I am not very knowledgeable about Docker files). I tried the tests suggested by Te-Wei Tsai and they worked as advertised. It is very nice to see low level controllers (wrapper code) talking to the middleware.

          I am also grateful to Te-Wei Tsai for showing me how to make multiple connections to a Docker image.

          Show
          rowen Russell Owen added a comment - The changes on github look reasonable to me (though I am not very knowledgeable about Docker files). I tried the tests suggested by Te-Wei Tsai and they worked as advertised. It is very nice to see low level controllers (wrapper code) talking to the middleware. I am also grateful to Te-Wei Tsai for showing me how to make multiple connections to a Docker image.
          Hide
          ttsai Te-Wei Tsai added a comment -

          Russell Owen To be clear, the simulator code is not the wrapper code by vendor. It just shows the TCP/IP message from the middleware code for the debug (a simple TCP/IP client). I am still waiting the reply from Andy that I should begin to work on the wrapper code or not.

          In addition, I am not sure your attitude that you want to use the Python to replace the wrapper code in cRIO or not. But I thought your answer is No from the last Friady's discussion with Andy. In the last Tuesday, I thought you had this intention in our phone-call. Please help to clarify your scope for this. And we may need discuss how to test your code in Chile at a good moment.

          Thanks!

          Show
          ttsai Te-Wei Tsai added a comment - Russell Owen To be clear, the simulator code is not the wrapper code by vendor. It just shows the TCP/IP message from the middleware code for the debug (a simple TCP/IP client). I am still waiting the reply from Andy that I should begin to work on the wrapper code or not. In addition, I am not sure your attitude that you want to use the Python to replace the wrapper code in cRIO or not. But I thought your answer is No from the last Friady's discussion with Andy. In the last Tuesday, I thought you had this intention in our phone-call. Please help to clarify your scope for this. And we may need discuss how to test your code in Chile at a good moment. Thanks!
          Hide
          rowen Russell Owen added a comment -

          I may be confusing "wrapper" and "middleware". I prefer to think of it as low-level controllers that run on the cRIOs and associated CSCs (which the vendor provided as a single process for all three CSCs).

          I believe my job is to replace CSC code with Python. It would be a much bigger job to replace the low level code on the cRIOs.

          Show
          rowen Russell Owen added a comment - I may be confusing "wrapper" and "middleware". I prefer to think of it as low-level controllers that run on the cRIOs and associated CSCs (which the vendor provided as a single process for all three CSCs). I believe my job is to replace CSC code with Python. It would be a much bigger job to replace the low level code on the cRIOs.
          Hide
          ttsai Te-Wei Tsai added a comment -

          I agreed the confusion part. However, vendor used the terms of middleware and wrapper in the documentation already. I prefer to be consistent to avoid the misleading from the future's maintainers. That person should begin from the documentation from Moog. The Jira ticket use the same terminology should help that person to know the status and history.

          Show
          ttsai Te-Wei Tsai added a comment - I agreed the confusion part. However, vendor used the terms of middleware and wrapper in the documentation already. I prefer to be consistent to avoid the misleading from the future's maintainers. That person should begin from the documentation from Moog. The Jira ticket use the same terminology should help that person to know the status and history.

            People

            Assignee:
            ttsai Te-Wei Tsai
            Reporter:
            ttsai Te-Wei Tsai
            Reviewers:
            Russell Owen
            Watchers:
            Russell Owen, Te-Wei Tsai
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:
              Start date:
              End date:

                Jenkins Builds

                No builds found.