Uploaded image for project: 'SAFe Program'
  1. SAFe Program
  2. SP-1717

MCCS Decoupling of tango from business logic

Details

    • Enabler
    • Must have
    • PI11
    • None
    • None
    • Obs Mgt & Controls
    • 1
    • 1
    • 5
    • Team_MCCS
    • Sprint 5
    • Hide

      This outcome is shared by SP-1716 & SP-1717

      SP-1716 aimed to understand what was causing instabilities in the MCCS code when executing 'long-running'commands. Then when we understood this, find a way to address this so that commands did not time out before completion. This was pretty well understood at the end of PI10 so the 'fix' plan was ready to go.

      SP-1717 aimed to adopt the most recent version (0.11) of the tango_base_classes. In many ways this was a revolutionary step because it was a means to push forward the adoption of asyncrhonisity in code execution, an initiative not only in MCCS but for all of the SKAO OMC ART.

      Crossover. The first instance of feature cross over between SP-1717 & SP-1716 was that because v0.11 tango_base_classes introduced asynchronisty, to a great extent time out during command execution was no longer a problem, in that a sequence of events required for a command to execute would in turn start and then complete before moving onto the next in the chain.

      As a result the implementing work of SP-1716 became a redunant action until a point at which SP-1717 completed and we could evaluate if further action was required or desired.Therefore during SP-1716 refocused towards supporting the KAROO team in their forming of an understanding and documentation the Reference Design and Implementation for asynchronous (long-running) commands SP-1640.

      Useful links:
      *************
      The repository where the mccs code base resides is: https://gitlab.com/ska-telescope/ska-low-mccs/. Specifically (https://gitlab.com/ska-telescope/ska-low-mccs/-/merge_requests/331) is the MR which facilitated the merge of v0.11 tango base classes into mccs. There are no specific seperate test cases or records asociated, but functional, integration and unit tests are presnt and have been appropriately refactored with respect to the base classes update. These can be reviewed here: https://gitlab.com/ska-telescope/ska-low-mccs/-/tree/main/testing/src/tests/

      Our work in updating the CI templates referenced https://confluence.skatelescope.org/display/SE/Migration+to+the+Central+Artefact+Repository, which we have fed back comments to the System Team.

      An interim demo was given at System demo 11.1, the recording and presentation of which can be obtain from: https://confluence.skatelescope.org/display/SE/2021-07-08+OMC+ART+System+Demo+11.1

      Quoting a section of the outcome of MCCS-400 "A major outcome, which was not initially anticipated, is the embrace of asynchrony across the entire codebase. This was achieved by moving the message queue functionality from the Tango device into the component manager. Rather than reimplement it into each component manager, a MessageQueueComponentManager base class was created, and the DeviceComponentManager was made to inherit from it. This made all our device-device interactions asynchronous in one fell swoop. But it also created a huge amount of work in refactoring device interactions, and rewriting tests, particularly integration tests. The message queue functionality was briefly presented at the Tango CoP meeting on 10 August. (https://confluence.skatelescope.org/display/SE/TANGO+CoP+Meeting+%2321+-+2021-08-10) "

      Show
      This outcome is shared by SP-1716 & SP-1717 SP-1716 aimed to understand what was causing instabilities in the MCCS code when executing 'long-running'commands. Then when we understood this, find a way to address this so that commands did not time out before completion. This was pretty well understood at the end of PI10 so the 'fix' plan was ready to go. SP-1717 aimed to adopt the most recent version (0.11) of the tango_base_classes. In many ways this was a revolutionary step because it was a means to push forward the adoption of asyncrhonisity in code execution, an initiative not only in MCCS but for all of the SKAO OMC ART. Crossover. The first instance of feature cross over between SP-1717 & SP-1716 was that because v0.11 tango_base_classes introduced asynchronisty, to a great extent time out during command execution was no longer a problem, in that a sequence of events required for a command to execute would in turn start and then complete before moving onto the next in the chain. As a result the implementing work of SP-1716 became a redunant action until a point at which SP-1717 completed and we could evaluate if further action was required or desired.Therefore during SP-1716 refocused towards supporting the KAROO team in their forming of an understanding and documentation the Reference Design and Implementation for asynchronous (long-running) commands SP-1640 . Useful links: ************* The repository where the mccs code base resides is: https://gitlab.com/ska-telescope/ska-low-mccs/ . Specifically ( https://gitlab.com/ska-telescope/ska-low-mccs/-/merge_requests/331 ) is the MR which facilitated the merge of v0.11 tango base classes into mccs. There are no specific seperate test cases or records asociated, but functional, integration and unit tests are presnt and have been appropriately refactored with respect to the base classes update. These can be reviewed here: https://gitlab.com/ska-telescope/ska-low-mccs/-/tree/main/testing/src/tests/ Our work in updating the CI templates referenced https://confluence.skatelescope.org/display/SE/Migration+to+the+Central+Artefact+Repository , which we have fed back comments to the System Team. An interim demo was given at System demo 11.1, the recording and presentation of which can be obtain from: https://confluence.skatelescope.org/display/SE/2021-07-08+OMC+ART+System+Demo+11.1 Quoting a section of the outcome of MCCS-400 "A major outcome, which was not initially anticipated, is the embrace of asynchrony across the entire codebase. This was achieved by moving the message queue functionality from the Tango device into the component manager. Rather than reimplement it into each component manager, a MessageQueueComponentManager base class was created, and the DeviceComponentManager was made to inherit from it. This made all our device-device interactions asynchronous in one fell swoop. But it also created a huge amount of work in refactoring device interactions, and rewriting tests, particularly integration tests. The message queue functionality was briefly presented at the Tango CoP meeting on 10 August. ( https://confluence.skatelescope.org/display/SE/TANGO+CoP+Meeting+%2321+-+2021-08-10 ) "
    • 11.6
    • Stories Completed, BDD Testing Passes (no errors), Outcomes Reviewed, NFRS met, Satisfies Acceptance Criteria, Accepted by FO
    • PI22 - UNCOVERED

    • SPO-1140

    Description

      Implement decoupling of tango from business logic using new base class state machines.

      Further development of MccsDeviceProxy

       

      Attachments

        Issue Links

          Structure

            Activity

              People

                s.vrcic Vrcic, Sonja
                v.mohile Mohile, Vivek
                Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Feature Progress

                  Story Point Burn-up: (100.00%)

                  Feature Estimate: 1.0

                  IssuesStory Points
                  To Do00.0
                  In Progress   00.0
                  Complete711.0
                  Total711.0

                  Dates

                    Created:
                    Updated:
                    Resolved:

                    Structure Helper Panel