Page History

• Executive summary (Aug. 4, 2022): Ric has highlighted an issue where grafana simultaneously sees the "tst" instrument running in both lab3 and neh (for example). This can be seen in this picture where there are two columns for "Time" "NumL0" and "Dead" in the white box.  Currently grafana uses "instrument" and "partition" to identify which data to display.  Ric proposes introducing a new concept: a "site" string.  Chris Ford also points out that multiple users using tstopr accounts (e.g. in lab3/neh) can conflict (like last settings of GUIs perhaps?).  This could conceivably be resolved by the resource manager that is in-progress.  Ric points out that most experts run as themselves (e.g. claus, caf, ...) and the active-detector file and log files go into their home directory (even if they use tstopr via procmgr.conf) so there is no conflict there.

fundamental concepts:

• partition (formerly known as "platform"): , a.k.a. primary readout-group) 
  • determines procmgr ports on the shared drp from primary readout group
  instrument: ued, tmo, rix (
  • (must be different for rix/tmo to share drp)
  • also maps to accounts that procmgr uses like tmoopr, uedopr, etc. using /etc/procmgrd.conf
  • also used by database to map to experiment-name for each "station" (https://pswww.slac.stanford.edu/lgbk/lgbk/ops#switch)
• instrument: ued, tmo, rix
• site (proposed, string): subnet (or location?) and the root xpm that procmgr uses?

...

options:
(1) we say "tst" can only run in one (subnet-plus-root-xpm)
(2) invent a new field for grafana: "site" (defined above)
(3) instrument field could include a new sub-string, like "site:instrument"

to represent "site" with an existing concept, could we make root-xpm number unique across the lab? no, because there can only be 0-6.

...

fundamental tuple:
site:instrument:partition(aka primary readout group)

some thoughts from cpo

• the issue only realistically occurs for tst for grafana (in other case, instrument names like tmo,rix,ued are the "site" (i.e. the subnet and root-xpm))
• doesn't feel right for expert-only tst case to impact general design for users
• feels like "hutch" gets used by default for grafana, but perhaps could be overridden by experts with optional kwarg overriding usage of hutch=tst to something more unique, e.g. tstued?

some thoughts from caf

• reusing the operator account "tstopr" is also a problem
• $HOME directory holds log files, active detectors file, etc.
• regarding "site," does the benefit of enabling "tst" (or any other instrument name) to be reused justify  the added complexity?
• A simple solution is to require unique instrument names.

some thoughts from ric

• 'Instrument' ("hutch") is used to access configDb and create the file path for recording

  • So, don't want to prepend 'site' too early

  • Maybe want to use it only with grafana or are there other places that would benefit?

• There is no proposed regulation on the 'site' value, so some people will ignore it, some will use their initials and some will do the intended thing

  • .cnfs would need to be changed in order to set it, which may be forgotten

  • Maybe change 'site' to 'instrument_prefix' (better name needed)?

• There is a worry that 'site' provides the illusion that a given partition is unique in a given site when this is not necessarily so

  • For example, the case when two different site names are given to the same physical site

• Maybe better to leave things as they are and deal with the very occasional occurrence of ambiguity in grafana by clicking on the  item, selecting View and hovering on the value.  This will show the source instance:
  Image Added