Description
The session metadata is a bit ill defined right now. The original definition idea is the following (to my understanding):
Configuration: a possible implementation of a session (think like a class definition)
Session: a running instance based on a configuration (think an instance of a class)
Session name: the name you used when running the unified shell, eg emir-test. This is filterable in Grafana
Session id: the id of cht eocnfiguration based on the file. Example is local-1x1-config.
Now the problem is that in the process manager, the session_name used is not the one that was supplied in the unified shell. It by default resolves to the username of the person making the session. In #786, a small fix exists to iniitalise the ERS handlers with the correct session name, butt his is a temporary solution.
This should be properly fixed. The scope would be within the Services major update, but also in the daqpytools future when the ERSKafka handler is split from one thing to an ERS parser and a generic Kafka handler.
Potential impact radius
Small/Isolated
Reason for change
Reduce technical debt
Suggested implementations
No response
Testing suggestions
Make sure it has the same behaviour as before
Anything else?
No response
Description
The session metadata is a bit ill defined right now. The original definition idea is the following (to my understanding):
Configuration: a possible implementation of a session (think like a class definition)
Session: a running instance based on a configuration (think an instance of a class)
Session name: the name you used when running the unified shell, eg emir-test. This is filterable in Grafana
Session id: the id of cht eocnfiguration based on the file. Example is local-1x1-config.
Now the problem is that in the process manager, the session_name used is not the one that was supplied in the unified shell. It by default resolves to the username of the person making the session. In #786, a small fix exists to iniitalise the ERS handlers with the correct session name, butt his is a temporary solution.
This should be properly fixed. The scope would be within the Services major update, but also in the daqpytools future when the ERSKafka handler is split from one thing to an ERS parser and a generic Kafka handler.
Potential impact radius
Small/Isolated
Reason for change
Reduce technical debt
Suggested implementations
No response
Testing suggestions
Make sure it has the same behaviour as before
Anything else?
No response