1. Section meeting 8th November 2017

2. Control System Evolution
Removal of some versions of some products as well changing the API and releasing under the same version of others (Athanasios)
Maven dependencies

3. Control System Evolution
What are the CO services/APIs you depend on and what CO services depends on your services? Do you think those dependencies are correct?
Services
CMW (+ tools)
InCA/LSA
CCDB
Tracing
Timing (+ tools)
Testbeds (would like access), Bamboo
Hardware installation (Steen?)
OASIS setup (OP?)
Products
Encore
Artifactory
Diamon
Make.generic
FESA
SILECS
LTIM
CBNG
Not used for our Expert GUIs but used for anything operational

4. Control System Evolution
What are the issues you currently see in the specific services you rely on and in the control system in general?
Services
CCDB
Some views are not efficient – for instance it would be very useful to have a table view of devices, showing one device per row and its fields being the columns.
This is linked with the wish-list for the FESA plugin
It is very annoying not being able to open several tabs with CCDB pages
As reported last year, modifications for classes distributed on many FECs can be very tedious (repeated event configurations for instance)
Copy-paste can result in destroying the original if we are not careful
InCA/LSA
We don’t want to know
Integrate FESA validation with INCA validation better
Turnaround too long for migration
Global devices can’t be operational
Tracing
Service is often down.
Kibana is far more powerful than Grafana for exploring messages.
Grafana dashboards are open to everyone – should be per-user.
Only the latest 5 days of data is readily available – more is sometimes useful.
Commitment to a stable, long-term solution ensuring we won’t invest time only to have to redo the efforts next year
Products
CBNG
BOB is very slow. Rudimentary feedback of build failures and dependency trees compared with Maven
LTIM
It is too complicated and error-prone to set it up.
A dedicated application could help?
Error messages sometimes lack details, making them next to useless for end users
FESA
Graph editor and data store summary is very useful and should be adopted/promoted
Better documentation
The instantiation file format should be revised, to have a single line per “info-unit” in order to allow grep’ing the files for values
No unified way to see the current configuration/settings: you need to open the FESA navigator + CCDB instance page
Exposing an interface for CMX (to be used by our code?)
Some concepts are hidden to the user and may lead to unwanted actions (e.g. device ID: I once moved to another FEC and renamed 35 devices while trying to duplicate them for a test bed)
Persistency files tend to create unexpected behaviours when FESA class versions are upgraded
Diplomatically speaking, the delivery is a nightmare
Duplication of the same info in multiple places in the .design

5. Control System Evolution
Are you satisfied with the current BE-CO DevOps process (e.g. build tools, workflows for release and deployment, etc.) and test infrastructure? What do you think should be improved?
Build
Should offer better management of dependencies
It would ne nice be able to release from another branch than trunk (for projects evolving in parallel, one branch could be for bug-fixing in the deployed version)
Official Make.generic available for Gitlab? (we have our own extension to support it)
Testing
Better FESA support for mocking, unit testing and CI
We will pursue this in BI next year
We are happy to collaborate with CO but will aim to have something ready pre-LS2
So don’t want to get delayed etc…

6. Control System Evolution
What are the key evolutions (new features, fixes, etc.) in CO services that you expect from us (before LS2/after LS2)?
Please do not add new constraints to currents paradigms (unlike FESA2 -> FESA3 transition)
If there is another big-bang, we don’t have the resources to redo all our classes again
Rumors of replacement for device-property model
Fine, but should be totally transparent for us

7. Control System Evolution
What is your opinion on the support and the different monitoring/diagnostics tools offered by BE-CO? What improvement could you suggest?
Tracing needs to be stabilized and improved
Looking forward to learning more about COSMOS
(Steen???)
Their visibility could be improved. Usually, we discover some nice tools only by chance when we get to debug a problem with an expert.
CO Portal for links???

8. Control System Evolution
How do you think the Control system should evolve; what should happen in general and in its specific components?
Evolving only when necessary
Just because components could be done in a cooler way, doesn’t mean it’s worth the cost
Only involve the users in the evolution process when absolutely necessary
As much as possible, automatic & transparent
They need to be much more integrated with each other, providing actual workflows
The designers of CCDB should sit next to the designers of the FESA plugin
Homogenous interface to developers

9. Control System Evolution
What would be your ideal-world control system?
One which allowed us to do all we need without having to ask support from CO
One which regularly informs us of new developments and new tools
Half-day bi-annual presentation from CO from each of CO’s products / services?

10. Other news… New LD Staff
New LD staff post unfilled
We chose 1 candidate
Who then got offered a more attractive offer at Microsoft Research
We will re-issue the post this week
I will revise a bit the job description
Less focus on RT & Java
More focus on software-engineering
In parallel, we might invite 1 candidate who could only do Skype interview
But this will be in parallel to republishing the post
Likely now that the post will be filled no earlier than March 2018

11. IP Phones News from the DH Analogue phones
BE has some 500 analogue phones or digital phones that are no longer compliant
Mobile or computer should be default for most users in future
I feel some pressure will come from GL on this…
Need to identify necessary new fixed digital phones
Paul needs material for his end of year talk by 5th Dec
Please send me your highlights in next few weeks!
Location
Action
Comments
Students
1-C01
New IP phone – Solution to share?
Students don’t have CERN mobiles. Old Alcatel IP phone
Stephane
1-C03
none
Already has an IP phone (no mobile)
Steen
1-C04
New IP phone
Already has mobile but prefers to use fixed line phone
Stephen
1-C05
Will assign IP phone number to mobile
Diogo
1-C06
Old Alcatel IP phone. Moves section 2018
Manuel
1-C07
Will assign IP phone number to mobile or computer
Guillaume
1-C09 --
Athanasios
Ana
1-C10
Doesn’t have CERN IP compatible mobile
1-C11
Students don’t have CERN mobiles

12. Merit 2018 MERIT MERIT Interviews to take place much earlier
Starting 27th Nov
Please note the very early deadline!
Will need to start before Christmas
Signed by GL by 6th March
Mini-MERIT less useful as a bit late now…

13. Java @YETS JDK 1.8_152 released
Will be Installed on Linux (including VPCs)
Without /usr/java/jdk symlink pointing to it
Allows people to use it for their tests, but does not affect operations
I (& OP) already asked why not Java 9!
Awaiting answer…
On canary machines /usr/java/jdk symlink already pointing to new version
CO devtools team switch the continuous integration tests (bamboo, superbuild) to use the new JDK
Upgrade in SDC Eclipse (as soon as it’s available)
If there are no problems, in early January, switch the /usr/java/jdk symlink to the new jdk
keep the old version installed (just in case)
Test our Expert GUIs early YETS…