Agenda
Short Term (Before 2020OCT)
- Maintenance (Bug-fixing / Improvements)
- Test Cases Stabilization (~30 remaining tests) – 2020JUN / 2020AUG
- Last Python 3 Porting Details – 2020APR / 2020JUN
- Any bug found by Phase B or Subsystems porting
- Makefile Refactoring Pending Tasks – 2020JUN / 2020AUG
- BulkDataNT: Check data rate behavior with unreliable receiver configured with different qos_profile instead of a different qos_library
Mid Term (Before 2021FEB)
- Finish ACS Makefile Refactoring – 2020DEC / 2021JAN
- Restart efforts with other subsystems
- RHEL / CentOS 8 Support – 2020OCT
- Should be 1 week of effort at most
- Redesign Notification Service – 2020DEC
- TMCDB Split analysis
- Homogenize logs sent to XML files and Kafka
- Investigate problem with BulkDataNT and 2 NICs
- Investigate BulkDataNT upgrade to latest RTI DDS version
- ComponentCaller to handle methods with Callbacks
The actual decision of what gets implemented will be discussed on each ACS Requirements Gathering meeting, since it is not clear whether with current resources it would be possible to implement all of the listed tasks by 2020DEC
Long Term (TBD)
- ACS and Java Modules – 2021FEB
- This can wait, but ACS could investigate in the direction of offering support for Java Modules
- Ralph has already started some prototyping with the use of Java modules
- ACS C++ Thread modernization – 2021JUN
- Most users have moved away from threads offered by ACS due to complexity and unreliability
- Still, light weight interface, similar to std::thread and/or boost::thread could be implemented in the future
- Support current interface for backwards compatibility and flexibility in configuring thread details
Other Input
- TMCDB Separation
- Put into the Mid Term plan
- Redesign C++ Logging
- The idea is to change the underlying technology ACE/log4cpp for a more modern one such as boost log
- Homogenize how the logs are being sent to XML and kafka in order to allow logs re ingestion from XML logs
- Scheduled for mid term development
Conclusions
2020JUN
- Maintenance – Bug Fixing / Improvements
- Test Cases Stabilization
- Python 3 Porting Polishing
- Makefile Refactoring
- BulkDataNT Investigations
Action Items
- Tomas Staigto share Notification Service replacement plans
- Tomas Staig to work with Johnny Reveco, Jorge Avarias, Jonathan Antognini and other people in figuring out the details of the current state of the TMCDB split and what needs to get implemented in the future
4 Comments
Ralph Marson
I'm surprised to see the RedHat-8 porting for cycle 9 i.e., before 20201FEB. An OS update is not included in the control sub-system cycle 9 planning. Unless there is a compelling reason we need to switch soon I suggest the OS update be more broadly planned for cycle 10. RedHat-7 is scheduled to be retired in June 2024.
I think completing the TMCDB separation is higher priority than redesigning the notification service and the OS update mentioned above. The monolithic TMCDB is restricting changes or requiring mandatory back-ports.
Like the Python 3 and the OS update the move to Java modules should involve ICT wide planning.
ACS thread modernization can be made lowest priority. The BL correlator subsystem has started using C++11 threads using a simple pattern that provides an ACS logger to the thread.
Tomas Staig
It is only support for RHEL 8 in ACS, which is already around 99% compatible anyway. The port of the ALMA SW to RHEL 8 should be planned more carefully and for future releases.
Moving to Java modules is a longer term planning, however, for ACS to give support for them could be a shorter development. I'm thinking at least to give better compatibility with external software that already makes use of modules, such as JavaFX.
Rodrigo Amestica
I think that the bulk-data effort to consolidate the BulkDataCache should appear in the shorter or medium term planning.
Kris Haskins
For BulkData: I think we'd like to see support for unreliable receivers, and support for hosts with multiple network interfaces. I'm not sure when these should fall in the timeline, nor how much effort each will take.