Rule registration should fail if YAML contains multiple actions
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 6.5k
- Forks
- 787
- PR merge metrics
- No merged PRs in 30d
Description
SUMMARY
Users can register rules containing multiple actions, but this is invalid. It will only use the last action in the file, silently ignoring the rest.
ISSUE TYPE
- Bug Report
STACKSTORM VERSION
st2 2.10.3, on Python 2.7.12
OS / ENVIRONMENT / INSTALL METHOD
N/A
STEPS TO REPRODUCE
Create this rule:
---
name: relay_to_chat
pack: icinga2
description: Post to chat when icinga2 service state changes
enabled: false
trigger:
type: icinga2.event.state_change
criteria:
trigger.type:
pattern: "StateChange"
type: "eq"
trigger.state_type:
pattern: 0.1
type: gt
action:
ref: chatops.post_message
parameters:
message: Icinga2 service {{trigger.service}} on host {{trigger.host}} has changed its state to {{ trigger.state|int }}, state type {{ trigger.state_type|int }}
{{trigger.check_result.output}}
channel: 'general'
ref: core.local
parameters:
cmd: "echo foobar"
Note the multiple actions.
Register with sudo st2ctl reload --register-rules, and then examine the above rule with st2 rule get icinga2.relay_to_chat
EXPECTED RESULTS
One of two things should happen:
1/ (Preferred) Registration should fail with some sort of fatal ERROR, e.g. "ERROR: Rule has multiple actions. Only a single action is allowed"
OR
2/ It should register and allow me to have multiple actions in a rule.
ACTUAL RESULTS
The rule is registered successfully, but only the last action takes effect:
extreme@ewcdemo:/opt/stackstorm/packs/icinga2/rules$ sudo st2ctl reload --register-rules
Registering content...[flags = --config-file /etc/st2/st2.conf --register-rules]
2019-03-07 16:52:50,606 INFO [-] Connecting to database "st2" @ "127.0.0.1:27017" as user "stackstorm".
2019-03-07 16:52:50,614 INFO [-] Successfully connected to database "st2" @ "127.0.0.1:27017" as user "stackstorm".
2019-03-07 16:52:51,047 INFO [-] =========================================================
2019-03-07 16:52:51,047 INFO [-] ############## Registering rules ########################
2019-03-07 16:52:51,048 INFO [-] =========================================================
2019-03-07 16:52:57,908 INFO [-] Registered 12 rules.
##### st2 components status #####
<snip>
extreme@ewcdemo:/opt/stackstorm/packs/icinga2/rules$ st2 rule get icinga2.relay_to_chat
+---------------+-------------------------------------------------+
| Property | Value |
+---------------+-------------------------------------------------+
| id | 5c5a137c67824f533c57d138 |
| uid | rule:icinga2:relay_to_chat |
| ref | icinga2.relay_to_chat |
| pack | icinga2 |
| name | relay_to_chat |
| description | Post to chat when icinga2 service state changes |
| enabled | False |
| action | { |
| | "ref": "core.local", |
| | "parameters": { |
| | "cmd": "echo foobar" |
| | } |
| | } |
| context | |
| criteria | { |
| | "trigger.type": { |
| | "pattern": "StateChange", |
| | "type": "eq" |
| | }, |
| | "trigger.state_type": { |
| | "pattern": 0.1, |
| | "type": "gt" |
| | } |
| | } |
| metadata_file | rules/relay_to_chat.yaml |
| tags | |
| trigger | { |
| | "type": "icinga2.event.state_change", |
| | "ref": "icinga2.event.state_change", |
| | "parameters": {} |
| | } |
| type | { |
| | "ref": "standard", |
| | "parameters": {} |
| | } |
+---------------+-------------------------------------------------+
extreme@ewcdemo:/opt/stackstorm/packs/icinga2/rules$
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the rule-registration entry point exercised by sudo st2ctl reload --register-rules, using the YAML example and st2 rule get output to reproduce the behavior. Trace how repeated action entries are parsed and validated, then add coverage for the multiple-action case and confirm registration either rejects it or explicitly supports it.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- devops
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100