Immutable/default action parameters for aliases (ChatOps)

[arm4b]

There is already mechanism to set optional parameter in alias:

formats:
  - "google {{query=StackStorm}}"

Problem

But what if we want to add simple hardcoded chatops command and hide unneeded logic behind the default/immutable action parameters?
I think that good ChatOps commands could be simple and easy to remember, without MANY optional parameters. Example case:

To do that, we need to create additional action with default parameters, which will trigger another action. I do this way almost everywhere (bad way): https://github.com/armab/st2-chatops-aliases/tree/master/actions

Proposal

The proposal is to allow setting from alias default/immutable action parameters.

Here is an example how it could look:

---
name: chatops.deploy
action_ref: packs.install
description: Deploy ChatOps pack from `armab/st2-ansible-chatops` GitHub repo
formats:
  - "deploy chatops"
# these lines were added
# naming/structure is doubtful, but you got the idea
action_parameters:
  packs: "st2-ansible-chatops"
  repo_url: "armab/st2-ansible-chatops"

Here you can see that behind simple and immutable/hardcoded ChatOps command:

!deploy chatops

stands:

st2 run packs.install packs=st2-ansible-chatops repo_url=armab/st2-ansible-chatops

---

This simplifies things a lot, making existing actions more reusable by aliases.

[arm4b]

Another limitation is when there is need to edit parameter value coming from chat.
Here is an example when I need to trim unneeded http:// from parameter (added by slack chat).

Instead of writing this action:
https://github.com/armab/st2-chatops-aliases/blob/master/actions/server_status.yaml#L20
and use action in alias:
https://github.com/armab/st2-chatops-aliases/blob/master/aliases/server_status.yaml

I could do everything in single alias:

---
name: chatops.server_status
action_ref: ansible.command
description: Show status for hosts
formats:
  - "status {{host}}"
# added
action_parameters:
  hosts: "{{ host|replace('http://', '') }}"
  module-name: ping

---

The intent is to avoid ugly behavior when one action should be created to trigger another action, because alias is limited.

Before: alias -> helper action (pre-processing) -> core action
->
After: alias -> core action

[manasdk]

@armab - appreciate the report.

Immutable parameters

My initial gut is that this make the ActionAlias look too much like an Action definition so I wanted to avoid doing so however after I think about it more it pushes towards a fewer core actions and some more aliases.

The intent is to avoid ugly behavior when one action should be created to trigger another action, because alias is limited.

In reality adding an extra action to support specialized default or immutable values is perfectly reasonable but it does mean that an Alias author is also required to be an action author. Seeing that this adds flexibility I believe there is value in supporting immutable param in an ActionAlias.

Transforming parameter values

This one I am on the fence about. This really makes ActionAliases way more complex and to some extent takes away from the intent of an ActionAlias.

In the case of {{ host|replace('http://', '') }} is an issue with the medium i.e. slack so the best place to handle is the adapter. the ActionAlias has no context about the specific text based application that is being used here and not all chat clients will behave the same therefore the normalization would have to come from the medium adapter.

Generally though I am unsure if we should support such transformations. I would want to see atleast a handful(2 maybe) of usecases to be convinced about this one.

[manasdk]

@jfryman - Thoughts? You may have had similar experiences using ActionAlias and can share some data points to help figure out transformation support.

[arm4b]

Of course, under {{ host|replace('http://', '') }} it could be any Jinja-powered expression like conditional (what is pretty flexible). Creating additional action to do that - looks like overcomplication for me.

^^ that was just real example.

[arm4b]

Case 3. Parameter renaming for ChatOps

Imagine you don't like parameter name inside some action. For ChatOps you want something more readable, because ChatOps commands are simple shortcuts/representation for more complex things.

Let's rename it. For the moment it's possible to do only by creating additional action in the middle.
Here is an example how it could be with single action alias:

---
name: chatops.server_status
action_ref: ansible.command
description: Show status for hosts
formats:
  # avoid this
  #- "status {{some_strange_and_long_parameter}}"
  - "status {{host}}"
# added
action_parameters:
  # note parameter name
  some_strange_and_long_parameter: "{{ host }}"

Case 4. Inject several alias parameters into acton parameter value

This action and this alias could be transformed into single alias:

---
name: chatops.ansible_package_update
action_ref: ansible.command
description: Update package on remote hosts
formats:
  - "update {{package}} on {{hosts}}"
# added
action_parameters:
  # note 2 variables coming from chatops
  # and injected into one action parameter
  extra-vars: "hosts={{ hosts }} package={{ package }}"

[manasdk]

Parameter renaming

The user sitting in chat is never really exposed to parameters except help. The person writing the ActionAlias is but there is no getting around that in either case. Also, if a param is poorly named/inconvenient then fixing the action is perhaps the better approach - right? It is true that not actions will be editable and/or the action could be from a curated and safe to consume as-is pack with no intent to modify the pack.

Case 4. Inject several alias parameters into acton parameter value

Alright this is beginning to get a little extreme but I hear your overall point.

My primary push-back is that an ActionAlias is not an action and is quicky beginning to pick up action semantics.

However, I see that having an ability to define/re-define parameters does provide flexibility. So maybe you won me over 😄 . The impl may have limitations along the lines of once an ActionAlias contains a parameters section then those are the only parameters used for execution.

[arm4b]

Personally I found this approach with creating middle-man actions pretty confusing.

This looked ugly for me:
action alias -> helper action -> ansible integration pack action -> ansible binary

So I removed ansible pack from the chain to reduce number of agents:
action alias -> helper action -> ansible binary
what means that I don't need ansible pack anymore (felt strange here). What's the reason to use pack if I can use binary here and reduce complexity?

So after all, good logic for me looked like:
action alias -> ansible integration pack action

Thus core and integration packs could be more reusable.
Alias could be something like 1-click shortcut behind the real action, without middle-man.

[manasdk]

This would definitely inject more capabilities in ActionAlias. I suspect it might have impact on Action and ActionAlias interplay; lets see how this ends up.

[jfryman]

To @armab's point, there are still a lot of layers to wire something up to ChatOps. I ran into a similar problem, where I had to create an alias, create a new workflow, and then tie those together to wrap my chatops command up in sufficient way. (see https://github.com/frymanio/st2-frymanio). I sort of reconciled this at first as it allows me to have workflows I can expand upon later, and the scaffolding is there. But, this quickly became burdensome for the simple and quick actions.

I like this proposal, because it's cutting down on friction for the beginning uses.

In terms of transforming data: it's clear we need an answer here. It keeps coming up, and shelling out to some helper action to transform data isn't ideal. I would be open to explore the transformation in an alias. Initially I thought the ActionAlias isn't the place for this, but if we cut out Workflow, then it's the only logical place for it to be.

The way I look at this proposal is exactly the same thing we talk about when we express workflow. There needs to be a clear way to restrict the actions of a user to select actions. Creates trust and enforces safety. If there is a way to do this without having all the scaffolding, I think that's a win.

[pixelrebel]

I’m working on an action alias that wraps an ansible.playbook action. I need to specify the playbook and inventory files in the alias yaml file. I tried adding a parameters block as described here: https://docs.stackstorm.com/chatops/aliases.html#key-value-parameters , but this fails to load with error:

ValidationError: Additional properties are not allowed ('parameters' was unexpected)

Is this the crux of this issue, or am I just doing it wrong?

[manasdk]

@pixelrebel What version of stackstorm are you using?

Please run st2 --version