Disable expiration date

[jacquelinegarrahan]

This PR implements an expiration date for alarm disablement. Instead of true/false, the enabled message may use a future ISO time string, which the server then uses to schedule re-enablement. The configuration menu has also been updated with a date-time picker and a relative date dropdown. Selection of a date clears the enabled setting.

[kasemir]

Great, let me look though this early next week.

What's the expected level of compatibility, listed roughly most-important first:

• Can the 'new' server handle data from an existing Kafka setup, i.e., can I simply stop the old alarm server, upgrade it, start the new alarm server?
• Will 'old' GUI clients work with a 'new' server?
• Can we import 'old' exported XML config files into the 'new' setup?
• Will an 'old' server work with 'new' clients? Yes, as long as I don't use the 'new' client to configure an alarm with the new type of expiring disablement?

[kasemir]

Well, I've tested the basic cases of disabling an active alarm "until..", and then either letting the alarm condition persist or clear and re-enter. Either way, the alarm was disabled and then re-appeared after the "until..." time.

The UI code in ItemConfigDialog currently has constants like “6 hours” both where it populates the drop-down and where it parses it. When I added "5 minutes" to simplify tests, I had to do that in two places.
The parser could for example use org.phoebus.util.time.TimeParser.parseTemporalAmount so it handles a variety of durations, and the code that fills the drop-down could get the options from a preference, with the current values as default.
That way, each site can add their own settings, like “8 hours” if a site has 3 shifts per day, or “5 minutes” to simplify tests.

When a trigger PV is enabled or disabled, that state is clearly indicated in the alarm tree, and it also shows in the ItemConfigEditor. When instead using "Disable until: ...", however, that's not fully obvious in the GUI. When you later open the ItemConfigEditor, it simply appears disabled, no 'until' time is shown. An easy solution would be to show the date and time until the alarm is disabled. This would also allow disabling for e.g. 5 hours by simply selecting the target time, even if "5 hours" is not listed in the drop down.

When changing the configuration several times between enabled, disabled, enabled, disabled until ..., I keep getting it into a broken state where the alarm server will issue messsages in a loop.
The messages will be a flurry like this, where the "enabled":"2021-09-27T17:54:57.372236" has actually passed 3 minutes ago, so it should be re-enabled by now:

CreateTime:1632758360781: state:/Accelerator/Top: {"severity":"MAJOR"}
CreateTime:1632758360781: state:/Accelerator: {"severity":"MAJOR"}
CreateTime:1632758360781: config:/Accelerator/Top/ky9:tank: {"user":"ky9","host":"mac117944","description":"ky9:tank","enabled":"2021-09-27T17:54:57.372236"}
CreateTime:1632758360781: state:/Accelerator/Top/ky9:tank: {"severity":"OK","message":"Disabled","value":"","time":{"seconds":1632758360,"nano":781839000},"current_severity":"OK","current_message":"OK"}
CreateTime:1632758360781: state:/Accelerator/Top: {"severity":"OK"}
CreateTime:1632758360781: state:/Accelerator: {"severity":"OK"}
CreateTime:1632758360781: config:/Accelerator/Top/ky9:tank: {"user":"ky9","host":"mac117944","description":"ky9:tank"}
CreateTime:1632758360781: state:/Accelerator/Top/ky9:tank: {"severity":"MAJOR","latch":true,"message":"HIHI_ALARM","value":"100.0","time":{"seconds":1632758133,"nano":756291000},"current_severity":"MAJOR","current_message":"HIHI_ALARM"}
CreateTime:1632758360781: state:/Accelerator/Top: {"severity":"MAJOR"}
CreateTime:1632758360781: state:/Accelerator: {"severity":"MAJOR"}
CreateTime:1632758360781: config:/Accelerator/Top/ky9:tank: {"user":"ky9","host":"mac117944","description":"ky9:tank","enabled":"2021-09-28T11:54:49.61881"}
CreateTime:1632758360781: state:/Accelerator/Top/ky9:tank: {"severity":"OK","message":"Disabled","value":"","time":{"seconds":1632758360,"nano":781889000},"current_severity":"OK","current_message":"OK"}
CreateTime:1632758360781: state:/Accelerator/Top: {"severity":"OK"}
CreateTime:1632758360781: state:/Accelerator: {"severity":"OK"}

[kasemir]

Found one way to get into the broken state:

• Create new Kafka setup with "Accelerator" alarm topic.
• Start alarm server and GUI
• Add top level "Top" component (/Accelerator/Top)
• Add some PV which happens to be in alarm (/Accelerator/Top/ky9:tank)
• Use alarm tree to Configure PV to "Disable Until: ... 1 day" -> It appears disabled
• Use alarm tree again to Configure PV to "Disable Until: ... 12 hours" -> It appears disabled
• Use alarm tree once more to Configure PV to "Disable Until: ... 6 hours" -> flurry of messages shown below.

In this case, the "enabled":"2021-09-27T18:31:18.78767" is 6 hours into the future

CreateTime:1632760444300: state:/Accelerator/Top: {"severity":"MAJOR"}
CreateTime:1632760444300: state:/Accelerator: {"severity":"MAJOR"}
CreateTime:1632760444325: config:/Accelerator/Top/ky9:tank: {"user":"ky9","host":"mac117944","description":"ky9:tank","enabled":"2021-09-27T18:31:18.78767"}
CreateTime:1632760444325: state:/Accelerator/Top/ky9:tank: {"severity":"OK","message":"Disabled","value":"","time":{"seconds":1632760444,"nano":325777000},"current_severity":"OK","current_message":"OK"}
CreateTime:1632760444325: state:/Accelerator/Top: {"severity":"OK"}
CreateTime:1632760444325: state:/Accelerator: {"severity":"OK"}
CreateTime:1632760444325: config:/Accelerator/Top/ky9:tank: {"user":"ky9","host":"mac117944","description":"ky9:tank"}
CreateTime:1632760444325: state:/Accelerator/Top/ky9:tank: {"severity":"MAJOR","latch":true,"message":"HIHI_ALARM","value":"100.0","time":{"seconds":1632760443,"nano":819977000},"current_severity":"MAJOR","current_message":"HIHI_ALARM"}
CreateTime:1632760444325: state:/Accelerator/Top: {"severity":"MAJOR"}
CreateTime:1632760444325: state:/Accelerator: {"severity":"MAJOR"}
CreateTime:1632760444346: config:/Accelerator/Top/ky9:tank: {"user":"ky9","host":"mac117944","description":"ky9:tank","enabled":"2021-09-27T18:31:18.78767"}
CreateTime:1632760444346: state:/Accelerator/Top/ky9:tank: {"severity":"OK","message":"Disabled","value":"","time":{"seconds":1632760444,"nano":346882000},"current_severity":"OK","current_message":"OK"}
CreateTime:1632760444346: state:/Accelerator/Top: {"severity":"OK"}
CreateTime:1632760444346: state:/Accelerator: {"severity":"OK"}
CreateTime:1632760444346: config:/Accelerator/Top/ky9:tank: {"user":"ky9","host":"mac117944","description":"ky9:tank"}
CreateTime:1632760444346: state:/Accelerator/Top/ky9:tank: {"severity":"MAJOR","latch":true,"message":"HIHI_ALARM","value":"100.0","time":{"seconds":1632760444,"nano":316125000},"current_severity":"MAJOR","current_message":"HIHI_ALARM"}
CreateTime:1632760444346: state:/Accelerator/Top: {"severity":"MAJOR"}
CreateTime:1632760444346: state:/Accelerator: {"severity":"MAJOR"}

[jacquelinegarrahan]

Hi @kasemir, I've fixed the broken state bug, namely a bug generating a config message on alarm cancel, which was producing an enabled message.
In response to your compatability questions:

• Can the 'new' server handle data from an existing Kafka setup, i.e., can I simply stop the old alarm server, upgrade it, start the new alarm server? Yes
• Will 'old' GUI clients work with a 'new' server? No, the enabled json will not be handled correctly. Would you expect it to just show disabled in the case of dated disablements?
• Can we import 'old' exported XML config files into the 'new' setup? Yes
• Will an 'old' server work with 'new' clients? Yes, as long as I don't use the 'new' client to configure an alarm with the new type of expiring disablement? Yes

As for the other UI items, I will be passing this PR over to another team member, as I'm formally transitioning roles this week. Thank you for your patience.

[kasemir]

Thanks for the fix, will try that in about a day and then I think we can merge this.
The details of configuring the options from preferences can be added later.
As for compatibility, looks like there's a fair amount, and sites that cannot update all at the same time can start by updating the clients, simply not use the new feature, then update the server last.