Status Weighting Rules

[aso1124]

Allow customization of how a signal status affects the overall status for the step it belongs to.

Each step can have a set of weighting rules defined for it. The user will be able to configure signals as either contributing to the status calculation, or exclude them entirely

1. Worst case wins (default): the step status is the same as the worst status for any of its signals (i.e. one signal is red, the step is red)
2. Percentage evaluation: the step status is set if a certain percentage of signals in the step are in warning/critical. There should be gradations ... e.g. if 25% of signals are red, then the step goes yellow; if 50% of signals are red, the step goes red.
   In the percentage scenario, we also need to allow the user to set Critical Signals that will override the percentage calculations - if Critical Signals are set, they basically take precedence and set the Step status based on their state. This is a bit complex and needs a little more thought .. for instance, what if the percentage rule would set the step to red, but there's a Critical Signal that is only in yellow? Does the step go yellow or red?

[khpeet]

Some initial thoughts/opinions:

• Any signal marked as critical should override any percentage based config. (i.e - If I set 50% threshold, and only 25% of signals are red, BUT there is a critical marked signal in that 25%, the step should still be fully critical/warning state).
• Should we do static gradations, or just simply allow the user to choose a percentage value between 0-100 for any given step? (via textbox) - That may be simpler, and is easily calculated (and mimics how this is done in Workloads)
• If no step percentage is configured AND no signals under that step are marked as critical (to override any status), then the default is how the step status is implemented today