Details
-
Feature
-
Not Assigned
-
None
-
Data Processing
-
-
-
3
-
3
-
Team_YANDA
-
Sprint 5
-
-
-
-
12.4
-
Stories Completed, Integrated, BDD Testing Passes (no errors), Outcomes Reviewed, NFRS met, Demonstrated, Satisfies Acceptance Criteria, Accepted by FO
Description
In SPO-944 we realised an integration of the CBF-SDP emulator sender into Mid.CBF. This work was done as a one-off though, without code being committed to any repository, and instead using a custom-built Docker image (available on Nexus). This created some technical debt, which is what's being addressed here.
There are two main aspects that need attention:
- Code: the Tango device wrapping the emulator needs to act like a drop-in replacement of the CbfSubarray. It currently inherits from SKASubarray, which doesn't provide all the commands and attributes required for this drop-in replacement to work. It is believed that by inheriting from a different class (also part of the lmc base classes package) the emulator Tango device should be able to act as a replacement for the CbfSubarray without impacting the rest of the system.
- Deployment: To deploy the emulator Tango device we need to start a device server that starts this new device instead of the original. Additionally, at some level there must be an option to choose between using the original CbfSubarray or the emulated one. Initial discussions suggested that this should be handled at the highest level possible – i.e., by creating a new umbrella chart in SKAMPI to clearly separate both use cases.
Assumptions:
- Inheriting from the new class in lmc-base-classes the emulator Tango device as is, is sufficient to function as a drop-in replacement. The CIPA/CREAM is not available in case the base class needs changing.
- A persistant volume can be set up that contains a measurement set file for meta data. This relates to the stretch goal of automatic CI testing only.