Consistent validation of rule names

When registering rules from a dir or packs with st2ctl reload --register-rules there seems to be no validator for having spaces in the name of the rule.

$ cat test.yaml 

---
    name: "test spaces"
    description: ""
    enabled: true

    trigger:
        type: "linux.file_watch.line"

    criteria:
        trigger.event:
            type: "eq"
            pattern : "somthing"
    action:
        ref: "hubot.post_message"
        parameters:
            message: "broke"
            channel: "stackstorm"

~$ st2ctl reload --register-rules
Registering content...[flags = --register-rules]
2015-09-21 13:42:30,881 INFO [-] Connecting to database "st2" @ "0.0.0.0:27017" as user "None".
2015-09-21 13:42:30,924 INFO [-] =========================================================
2015-09-21 13:42:30,924 INFO [-] ############## Registering rules ########################
2015-09-21 13:42:30,924 INFO [-] =========================================================
2015-09-21 13:42:30,963 INFO [-] Registering rules from pack: default
2015-09-21 13:42:31,008 INFO [-] Loading rule from /opt/stackstorm/packs/default/rules/test.yaml.
2015-09-21 13:42:31,014 INFO [-] rule name is test spaces
2015-09-21 13:42:31,015 INFO [-] Found existing rule: default.test spaces with id: 5600070ee8b34d3a35e98ddf
2015-09-21 13:42:31,016 INFO [-] RuleDB(action=ActionExecutionSpecDB@35601936(ref="hubot.post_message", parameters="{'message': 'broke', 'channel': 'stackstorm'}"), criteria={'trigger.event': {'pattern': 'somthing', 'type': 'eq'}}, description="", enabled=True, id=5600070ee8b34d3a35e98ddf, name="test spaces", pack="default", ref="default.test spaces", tags=[], trigger="linux.file_watch.line")

this causes any rule with spaces on its name to be loaded on the database and causes issues on the webui (You cant select that rule as the UI will redirect to the main page)

Creating a rule from the UI seems to put a validator on the name.

Getting and listing the rules from the st2 client seems to not be affected by the spaces on the name.

~$ st2 rule get "default.test spaces"
+-------------+---------------------------------------+
| Property    | Value                                 |
+-------------+---------------------------------------+
| id          | 5600070ee8b34d3a35e98ddf              |
| ref         | default.test spaces                   |
| pack        | default                               |
| name        | test spaces                           |
| description |                                       |
| enabled     | True                                  |
| action      | {                                     |
|             |     "ref": "hubot.post_message",      |
|             |     "parameters": {                   |
|             |         "message": "broke",           |
|             |         "channel": "stackstorm"       |
|             |     }                                 |
|             | }                                     |
| criteria    | {                                     |
|             |     "trigger.event": {                |
|             |         "pattern": "somthing",        |
|             |         "type": "eq"                  |
|             |     }                                 |
|             | }                                     |
| tags        |                                       |
| trigger     | {                                     |
|             |     "type": "linux.file_watch.line",  |
|             |     "parameters": {},                 |
|             |     "pack": "linux"                   |
|             | }                                     |
+-------------+---------------------------------------+

so which one is it? Are spaces in rule names allowed? discouraged?

thanks!

Start with the st2ctl reload --register-rules registration path and compare its rule-name handling with the validator used when creating a rule from the web UI. Confirm the intended policy for spaces, then verify that registration, the web UI, and st2 rule retrieval behave consistently for invalid names.