# Dashboard meeting @ SURF (202410023)

- alerting support in dashboard?
- let EuroHPC Hosting Entities access dashboard
- how to do authentication?
- to avoid making all data public
- we still want some kind of token to avoid that malicious people can hack the VM
- integrate dashboard into EuroHPC FP
- let users make informed decisions about what are well-suited systems for the software they want to run
- would be ideal via a service account created by each hosting entity
- we're not tracking which exact installation is being used by the test
- full path to module file
- full path to the executable
- relevant EESSI environment variables (like which software subdir)
- detected CPU (archspec/archdetect)
- OS details (`/etc/os-release`)
- some data is being collected on the login node while it should really be collected at runtime in the job
- like hostname, Slurm job ID, path to module/binary, EESSI software subdir (or local stack), ...
- ReFrame variables, which are used in public dashboard to determine color/point share in plots, are controlled by ReFrame runtime running on the login node
- via after-run hook?
- issue for Caspar => https://github.com/EESSI/test-suite/issues/196
- if sites start uploading data into the dashboard then it has to be in the correct unified format
- dots in plots should be clickable to get more details
- like nodes used by the job, job ID, etc.
- should be able to select between different "groups"
- software.eessi.io, dev.eessi.io, local software stack, etc.
- ReFrame remote info can also be useful: https://reframe-hpc.readthedocs.io/en/stable/tutorial.html#accessing-cpu-topology-information
- sprint next week Maxim + CaspEr
- deploy VM in SURF Research Cloud
- public dashboard that can be shown to Vega+Karolina
- sbatch options should be used to ensure that nodes behind same leaf switch are used => issue for Caspar
- https://github.com/EESSI/test-suite/issues/197
- pull apart system and partition names => two dropdowns