You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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.

fundamental concepts:

  • partition (formerly known as "platform", a.k.a. primary readout-group) 
    • determines procmgr ports on the shared drp from primary readout group (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?

problem:
(1) grafana tst in lab3 conflicts with tst in neh (user will see results from both)
(2) tst in rix conflicts with tst in tmo (i.e. within one subnet)

currently two grafana "labels": instrument(e.g. tst), partition (primary readout group)
can run tst in lab3 or in neh.

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.

if we create "site":
- put it in the .cnf file or setup_env? (manually assigned).  ric proposes strings:
  e.g. lab3, ued, asc, neh2 (location+rootxpm), neh3 (location+rootxpm), txi
- when code creates grafana metrics, has to add "site" (drp, teb, meb, ami)
- have an extra drop-down menu on the grafana pages to select site
- site could be used by murali as well in databases

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

some thoughts from cpo:

  • the issue only realistically occurs for tst for grafana
  • 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?
  • No labels