Consistent Alarm naming convention between Alarm Table and Alarm Log Table

[jeonghanlee]

@shroffk and @kasemir

As we've discussed and agreed, here is the pull request to contain the consistent and meaningful naming convention within the Alarm Table and the Alarm Log Table.

Here is the table which we've developed so far.

Name	Proposed Name	Area
PV	PV	Alarm Table
Description	Description	Alarm Table
PV Severity	PV Severity	Alarm Table
PV Status	PV Message	Alarm Table
Alarm Severity	Alarm Severity	Alarm Table
Alarm Status	Alarm Message	Alarm Table
Alarm Time	Alarm Time	Alarm Table
Alarm Value	Alarm Value	Alarm Table
Config	Config	Alarm Log Table
PV	PV	Alarm Log Table
Severity	Alarm Severity	Alarm Log Table
Message	Alarm Message	Alarm Log Table
Time	Alarm Time	Alarm Log Table
Message Time	Alarm Log Time	Alarm Log Table
Current Severtiy	PV Severity	Alarm Log Table
Current Message	PV Message	Alarm Log Table
User	User	Alarm Log Table
Host	Host	Alarm Log Table
Value	Alarm Value
Time Delta	Time Delta	Alarm Log Table
Command	Command	Alarm Log Table
PV	PV	Alarm Log Table Search
Severity	Alarm Severity	Alarm Log Table Search
Message	Alarm Message	Alarm Log Table Search
Current Severity	PV Severity	Alarm Log Table Search
Current Message	PV Message	Alarm Log Table Search
User	User	Alarm Log Table Search
Time	Alarm Log Time	Alarm Log Table Search
Start Time	Start Time	Alarm Log Table Search
End Time	End Time	Alarm Log Table Search
Command	Command	Alarm Log Table Search

Please let me know what you think.

@shroffk we also have to work together to update the alarm documentation to reflect these changes.

Thanks,

@jeonghanlee, Soo Ryu, and @Sangil-Lee at ALS-U Controls, LBNL.

[shroffk]

Broadly it looks good... and it is a great effort to standardize across these applications/services

Is there a reason to choose PV Message vs keeping it PV Status... is this to link it to the other instances where Current Message also maps to PV Message

PV Status	PV Message	Alarm Table

[jeonghanlee]

We (You, Kay, and me) decided to use Message instead of Status to keep the modern EPICS convention which exists as far as I remember. Please correct me if I am wrong, since I am old and don't remember very well now. ;)

[jeonghanlee]

[jeonghanlee]

@shroffk when I took the screen capture, I saw there is inconsistent. I didn't have much attention about the query itself. Can you check what kind of query strings will be changed due to the new naming convention?

I will work with Sang-il to check them independently also. And I converted this PR to the draft.

[jeonghanlee]

@shroffk it turns out, we need to change all variable names between Alarm Server and Alarm Logger table within multiple java codes. We will come back after all relevant codes changes, and the corresponding tests.

[kasemir]

We ... decided to use Message instead of Status ..

Agree.

In the alarm log table, did the query always support "message=...&current_message=..." or is that a change from previously using "status...current_status..."?

As for "current" vs. "pv", the labels in tables etc. would now use "PV Severity", "PV Message", no more "Current ..", but would the log table still use "current_message=..." for the query? On one hand, that should become "pv_message=..." to be consistent, but that's more than just a cosmetic label, it's changing the query language.

[shroffk]

I think changing the search key words for the alarm log table would mean we would have to update the elastic index mapping and then migrate the data.

[kasemir]

That seems a bit much. Still, seeing "pv .." in all the GUIs but having to use "current_.." in the query can also be confusing. Would it make sense to hack this by patching the query, ...replace("pv_", "current_")? Or is there some way to alias properties in elastic?

[jeonghanlee]

I will come back when we have a better idea of how the query (new naming) works with elasticsearch and a better solution for consistent naming. I still think this is valuable, but I also agree that this seems a bit far from my original intention.