ControlSystemStudio / phoebus

A framework and set of tools to monitor and operate large scale control systems, such as the ones in the accelerator community.
http://phoebus.org/
Eclipse Public License 1.0
90 stars 90 forks source link

config_names is not a list in Phoebus Alarm Server #2843

Open minijackson opened 12 months ago

minijackson commented 12 months ago

As far as I know, config_names is documented as a comma-separated list, and used as a list in the Phoebus graphical client, but in Phoebus Alarm Server it is handled as a simple string.

For example, this settings.ini file:

org.phoebus.applications.alarm/config_names = Accelerator1, Accelerator2

Leads to a confusing error:

Error while fetching metadata with correlation id 97 : {Accelerator1, Accelerator2Talk=INVALID_TOPIC_EXCEPTION, Accelerator1, Accelerator2=INVALID_TOPIC_EXCEPTION}

Is there any plan to support multiple topics in Phoebus Alarm Server? The documentation seems to suggest as much.

georgweiss commented 12 months ago

Hmm, at ESS we deploy one alarm server instance per alarm config, so a list of config names is not needed/used.

@kasemir, @shroffk, can you comment as to supporting multiple configs in a single alarm server?

kasemir commented 11 months ago

One alarm server per config. You may have more than one config, and then you run more than one alarm server, one per config. All configs can be in the same Kafka setup. The GUI looks at one config per instance, but you may configure it to allow users to select between different configs. Alarm logger can log from multiple configs.

Example: Separate configs for accelerator, cryo, conventional facilities, target, because there are different control rooms for accelerator, cryo, conventional facilities, target. GUI for operators in cryo, conventional facilities, target control rooms are locked to that config. GUI in main control room defaults to accelerator config, but operators can select the other configs.

kasemir commented 11 months ago

config_name as used by the alarm server is one name. config_names may be a list, because

"When one or more comma-separated configurations are listed, the UI shows the selected name and allows switching between them."

kasemir commented 11 months ago

Mind you, the point here is not "he/she with the most alarm configurations and highest alarm server count wins".

It's hard enough to create and maintain one good alarm configuration, see https://controlssoftware.sns.ornl.gov/training/2022_USPAS/ for "Alarm System" overview and "Alarm Guidelines"

georgweiss commented 11 months ago

the point here is not "he/she with the most alarm configurations and highest alarm server count wins".

What a pity.

minijackson commented 11 months ago

Okay, using one alarm server per config is fine for me, although I think it would have been simpler for us to have one deployment. I think it'd be nice do document that the alarm server is to be deployed once per config.

I think there still is an issue right now, though. I see you've documented that config_name is used for the alarm server, but this doesn't seem to be the case right now. The alarm server is currently using config_names instead.

kasemir commented 11 months ago

The alarm server is currently using config_names instead.

Ouch, you're correct. Looks like that was never really noticed because most people run the alarm server with the -config command line option. All the common settings (CA/PVA address lists, kafka, ..) are in the preferences, and the alarm config for the specific instance then comes from the command line.

But when we now change it, that one person who does use the config_names will be bothered...

kasemir commented 11 months ago

Still, I'm in favor of fixing this, have AlarmServerMain look at the single config_name.