JCOP FWWG 2 Oct 2018: Framework QA & Cleanup
JCOP FWWG Meeting, 2 October 2018, 14H00
Present: Lukasz G (BE-ICS), Rafal K (BE-ICS), Jonas, Marc B, Mariusz, Riku, JC-T, Piotr, Christina (CMS), Matueusz L (ALICE).
Absent: ATLAS, LHCb, EP-DT
Minutes: ver 2.0, 2018-10-03, with clarifications from Cristina about the "post-install-action" usefulness in CMS
NEWS:
WinCC OA 3.15 patch P015 released by ETM; will be repackaged and made available for testing soon.
WinCC OA 3.16 FeaturePack should come in November (as a patch for 3.16); another feature pack is planned in Spring (April 2019, around Users Days date)
Technical workshop with ETM 28-29 September (in Eisenstadt) on the topics where we collaborate:
- NextGenArchiver: based on results of performance tests it was agreed that direct-queries are absolutely necessary and need to be supported; tentative timescale for initial implementation: end of 2018.
- Reviewed a tentative list of features for WinCC OA 3.17; among others, new map-widget, MQTT driver, security, git support in GEDI, etc. The roadmap will be clarified during CERN followup visit at ETM in January 2019. ETM made aware of CERN LS2 timing and implications for the choice of the version to upgrade to.
Frameworks are being readied such that a tested beta (or .0) version should be made available in November and handed over to users for validation before LS2 start.
Quality Assurance in Frameworks
presented by Marc B. (see slides); the presentation was delivered already to JCOP-CB members last week
Lukasz asks migration to gitlab of their internal components => partial response about the tooling in Riku's presentation about ComponentBuilder.
JC-T asked about tests in distributed systems; not yet there, but will need to be a part of validation tests, and likely also the vertical slice; docker (swarm, kubernetes) may be a technical solution to simulate large systems with non-trivial network topology.
JC-T asked about how many tests are run on the vertical slice and what is covered in unit tests. Explained that UNICOS-CPC functionality with JCOP Core is covered to large extent by the communication test; even though other cases are simpler, the "integration tests" provide significant coverage for most used functionality
JC-T: What about GUI tests? Squish-test abandoned, with no plan for direct replacement; in the future we look at making the panels testable using the uiConnect() features of object-oriented panels; some proof-of-concept exist, yet they could only be applicable to new or completely reworked panels.
Component Builder
presented by Riku S. (see slides)
Lukasz G: Is the tool open to other users? There are use cases for Vacuum where they would like to build a component.
CMS is planning to migrate to gitlab at some moment, and then they would be interested in using it,
The same for ALICE, in particular for fwISEG component that should be migrated to gitlab, and then automatic builds would be very welcome. The whole migration process will be followed-up by Mateusz and Piotr, with decision pending on the choice of location for the repository.
Decision: we should make the ComponentBuilder available to interested component developers.
Extensions of the fwInstallation Tool
presented by Mariusz S. (see slides)
Binaries used by experiments usually come from the framework itself; few of them are developed inhouse, at least for CMS and ALICE.
In CMS there exists already some extensions for fwInstallation. However, a mechanism that would allow to schedule the re-generation of FSM Tree from the components providing "leaves" would be welcome [clarification from Cristina].
What concerns the installation of binaries, for CMS internal components binaries are stored in the bin/fwComp/LIBWITHNOVERSION.DLL ,ie. non-versioned; the proposed <bin> tag of fwInstallationTool should support this.
Marc B: the cleanup function should not be reserved only for binaries, but for all other files that component developer would wish to move/remove/cleanup correctly (e.g. moving the test-panels and test-scripts to a dedicated folder).
JC-T: In the case of unCMW component there were two binaries installed, for RDA2 and RDA3; how should they be treated? Agreed that in such cases a custom postInstall should be used to install the "compatibility" RDA2 binary.
Proposal approved; Mariusz will choose the naming convention for the binaries, and then the Framework components should adhere.
Mechanisms for deprecation
presented by Piotr G. (see slides)
JC-T: for deprecated function, how would the alternative (replacement) function be suggested? For the scripts or libs it will be in the documentation (list of deprecated functions), but how to get an equivalent panels?
No objections to proposed mechanism (approved).
AOB
(Raised during coffe discussion after FWWG): ALICE is interested in having the new Elasticsearch-based log analysis tool tested/deployed in their infrastructure; to be followed up.