Discussion: Unified Connections File for All CERN Test Stands

[bdorney]

Brief summary of issue

We have several systems at CERN which are expected (and have) exist for a long time now:

• P5 v2b electronics (eagle33),
• P5 v3 electronics (eagel61),
• 904 coffin setup (eagel34),
• 904 firmware development setup (eagle64),
• QC8 (eagle26, and in the future eagle60 and eagle64),
• V3 R&D (eagle60)

Each time a new developer, or a developer to a new system, comes along they have to go through the trouble of setting up a new connections file and ensure the symlinks point correctly.

For those setups at CERN I would propose a shelf numbering schema and central tracking of the required connection file(s). This would reduce headaches when new developers/users come to try new systems (here user's would be for those stands that do not have a user account on the daq machine, e.g. gem904daq01).

For example:

• Shelfs at P5 use the numbering 01-99, and
• Shelfs elsewhere at CERN use the numbering schema 101-199,

And in the unlikely event we expand this to outside CERN:

• Shelfs outside of CERN use the numbering schema 201-299.

Additionally as shelf layouts are not expected to change much for each shelf this would mean the AMC13, and AMC's present are specified in the connections file.

Types of issue

• Discussion

Expected Behavior

Quality of life/standardization feature.

Context

New developers, or a developers using a test stand they are unfamiliar with, need to setup a connection file. To avoid confusion, mistakes, or lost time, it might be easier to just centrally track all systems.

@mexanick, @jsturdy, @BenjaminRS

[jsturdy]

This is currently in progress (but stalled) with machine profiles

• P5 will be simple, all the devices have sensible, programatically simple names, based on rack/U-number/uTCA slot, e.g.,
  • MCH: mch-s2e01-23-01
  • AMC: amc-s2e01-23-03
  • AMC13: amc-s2e01-23-13-t1 and amc-s2e01-23-13-t2
  • bridge (controlhub) PC: bridge-s2e01-23
• We could attempt to emulate this network DNS setup in 904 test-stands as well, which we already sort of have, modulo "sensibility"

[jsturdy]

Current machine setup script assigns slot/shelf based aliases in the /etc/hosts file, making programatic name resolution trivial (for CTP7s, for AMC13 and other cards, we may have to write a sysmgr module to assign the geographic IP addresses)
This can (with a few modifications) remove the need for a connections.xml file, instead relying on shelf/slot/type specifiers and creating the connection on the fly... have to think how best to proceed...

[mexanick]

I think at least at the short time scale we need to update the connections file. When we will be ready with automatic name resolution, we can drop it, but right now we don't have any other working mechanism. Besides we still need to keep the structure shelf-slot-card somewhere and having it in the repo is not that bad idea... Maintaining/checking the twiki could be ambiguous.

[jsturdy]

As anyone who's discussed this (and related) issue(s) with me knows, I'm fairly strongly opposed to having this connection file tracked inside cmsgemos, similarly as to how I oppose the chamberInfo.py file of gem-plotting-tools

Having this information version controlled: good idea
Having this type of setup specific information in the specific repository that uses the class of information it stores: bad (or at the very least dirty) idea

Currently gemxaas (XDAQ machine profiles with gemos specific configs) is living inside cmsgemos but I will be breaking it out into a separate repository (once I figure out how far down the rabbit hole I've already fallen with the changes). This will provide a repository agnostic, machine/lab specific set of common information. The zone config will probably require certain other packages to be installed, and will provide overrides of some default configs

In the meantime, gem904qc8daq is now using the "new" connection file (with a legacy connection for "shelf3")

• Shelf numbering is as set up in the sysmgr.conf
• AMC13 IP addresses are currently S/N based, but mapped in the /etc/hosts file, and can be changed to be assigned by sysmgr at some future point
• Other types of AMCs (e.g., GLIB) are currently set to have a slot based IP address and if you put one GLIB in the same slot of two separate uTCA shelves on the same subnet, as they will have the same IP address, I have no idea what the actual behaviour will be...
• For CTP7s this change is trivial, because you already can't talk to a CTP7 on a different local network, i.e., from gem904daq01 one can't run reg_interface or amc_info_uhal on a CTP7 connected to a network provide by gem904qc8daq (unlike any device running behind a controlhub)

[mexanick]

@jsturdy I agree with your reasoning. However we must provide a proper source of connection file for each setup at the moment, otherwise persons who operate them loose a lot of time. So I insist we need to provide a master connection file until we get another, better way of handling the things. This is a temporary and not the best solution, however we do not have any other ready solution at the moment and we must provide one. As soon as we get it done through the sysmgr.conf and /etc/hosts we will remove the master connection file.

[jsturdy]

As soon as we get it done through the sysmgr.conf and /etc/hosts we will remove the master connection file.

I am saying that this is already done (one can easily rerun the setupMachine script with the -C option to set up a system for communication with a CTP7, which sets up the appropriate files, modulo some manual change to pick the correct IP address of any AMC13s connected.)

[mexanick]

@jsturdy is there a documentation describing the connection methods in details (their imlementation in the xdaq)? I didn't see the update to connections.xml in the setupMachine script. So is the connections.xml completely outphased?

[jsturdy]

No, a default one is generated, assuming only CTP7s and based on the number of uTCA shelves the sysadmin sets up.
It requires no change wrt current operating modes.
This update is in my currently open and being finalized PR.

[mexanick]

Current legacy documentation should answer the questions raised during the above discussion