New runtime config item: "priority"?

[hjoliver]

[This arises from BoM project discussions].

Consider:

[runtime]
   [[NAME]]
        title = blah
        description = blah2
        URL = blah3
        priority = 1  # <-----!
        ....

The new item priority (or similar) would be provided to event handlers, to allow priority-based alerting. E.g. if some low-priority task suffers a CRITICAL failure, don't bother waking anyone up at three in the morning, just send an email.

To bodge this functionality in at the moment you have to repeat the event handler command line in every task (or in families with shared priority values) to add the priority value as a custom argument, e.g.:

failed handler = handler.sh %(name)s %(point)s 10  # priority = 10

but it would be cleaner and more transparent to have the concept built-in. And we could potentially use it for other things too (beyond just passing to event handlers) ... although nothing occurs to me right now [see my next comment below].

@cylc/core - seems a pretty good idea to me, and easy to support - what do you think?

(while we're at it, should title be provided to event handlers too?)

[matthewrmshin]

Yes, title should be one of the template variables for a custom event handler.

My initial thoughts on the main point:

1. At our site, we have delegated this functionality to the event handler commands, which have their own configuration files to modify the alerts a small number of tasks in some suites will receive. All other tasks get the default alerts.

2. If this is done via the suite.rc, we can have the event handler commands with the different types of alerts defined in a small number of families - which can inherited by the relevant tasks/families.

3. (If we are still keen on this...) A setting called priority at the top level will be confused as the queueing priority for submitting the task. (That was my immediate reaction when I first saw the title of this issue.) Suggest: event level placed under the [[[events]]] sub-sub-section?

4. (If we are still keen on this...) We need to consider that different events (e.g. execution and submission failure) for the same task may require different types of alerts.

[matthewrmshin]

P.S. the solution at point 2 (with no change to our current logic) can already handle point 4 neatly.

[hjoliver]

@matthewrmshin - in response to your points:

1. This functionality is delegated beyond Cylc here too, to Nagios monitoring configuration. However, I think information about how "important" a task is naturally belongs in the suite definition. Event handlers (etc.) should not need special information about specific tasks that might use them.

2. (I think you mean this is what we can do now, thanks to multiple inheritance? If so, true, but it would still be a cleaner suite definition if this proposal is implemented). [update: reread your point above -agreed].

3. Agreed that priority is too easily confused with the proposed internal queue priority, so we need a clearer name. (I'll keep using priority here in lieu of something better). But I disagree that it should be configured under [[[events]]] - IMO this is "top level" information. It's main use may be in event handlers, but there could be other uses. In fact I thought of another- we could potentially highlight "high priority" tasks the GUI somehow.

4. I don't see a problem as handlers can react to the priority level differently depending on the event - or have I missed your point?

In summary, I am still keen on this. It doesn't really give us new functionality, but this would be a nicer/cleaner way to do it (and more obvious to users) and also easy to implement, so I think we should do it ... I guess we just need to agree on item name and position (i.e. top level or under events section). I looked up synonyms of priority for a few ideas:

• rank
• level, or priority level
• transcendence (ha!, joking)
• importance, or importance level <----?
• criticality
• alert level