Should Registration Instances contain limited fields?

[slominskir]

After reviewing the alarm registration data from our existing alarm system it seems we may not need many overridable fields in registration instances as the vast majority of the time it appears the class defaults will suffice. The remaining few cases could be addressed by creating additional classes, including some classes which may only have one instance. The trade-off may be simplicity vs flexibility. It would be much cleaner and easier to reason about if instances had very limited fields and slightly less clumsy for sync processes that automatically keep the subset of alarms that are configured elsewhere up-to-date (From the CED for example). Further, it is a little more clumsy for ops to make changes, because to be most confident in updates they'd actually need to review EVERY instance of a class anyways to ensure there are no accidental (or previously correct, but now out-dated) instance overrides of the fields they are updating (and harder to find). It may just be easier to invest the extra up-front cost to ensure that every alarm "type" is directly accounted for as an alarm class.

[slominskir]

The limited set of instance fields may be:

• Name
• Class
• Producer (epicspv)
• Location
• Maskedby
• Screenpath

That means classes may be solely responsible for:

• Corrective action
• Rationale
• Priority
• On-delay
• Off-delay
• Category
• Point-of-Contact
• Latching
• Filterable

Note: The Name, Class, and Producer are already required and only found in the instance. The Location field is currently optional, and if not specified in the Instance, then inherited from the Class. We may re-consider this though and for simplicity just make Location always come from Instance. Special handling of one field may not be worth the complexity and awkward update process in which ops must check both class and instances anyway. Keep inheritance, but drop overrides

[slominskir]

Note: Memory (space) considerations are probably negligible due to the relatively small amount of data. However AVRO encodes all fields even if they're null, and even if they're the default value, so it will actually save space to remove all the null valued fields from instances.

[slominskir]

There is some existing data that suggests some fields must remain instance-level.

Examples where screenpath varies by instance here:

• box
• camac

Examples where latching varies by instance here:

• camac

These cases should be examined for correctness and/or ability to fold into additional classes.