Ability to pass context to workflow execution via the api

I'd like to call a mistral workflow via api/execute and pass in api_user and source_channel as part of the context similar to what I get when making a request from chatops. This is so I can run executions from another service or command line via the api but still have access to a slack user and channel to respond to.

As another option I considered passing the values to env but a mistral workflow does not take env.

The only other option I see now is to add a new parameter to all of my workflows.

Discussion with @Kami in #community:

john.welborn[12:52 PM]
Anyone have any suggestions about getting api/execute to pass in context, (containing 'source_channel' for example) just like hubot does? I've tried adding it to my requests.post call in data= just like 'action' and 'parameters' but its not showing up in the st2api.log for the request like I see with chatops.

kami[12:54 PM]
lemme check, including context in payload should work i think

[12:54]
or maybe it gets overriden somewhere

[12:55]
yeah, it looks like we dont support specifying base context now

[12:55]
we populate it ourselves

[12:55]
having said that, i would personally be fine with user supplying arbitrary context

[12:55]
of course, only the attributes which are not system / reserved which are supplied (overriden) by us

[12:55]
so if you open github issue for it we can have a look

[12:56]
please also include your use case

john.welborn[12:56 PM]
have a file and line number handy for where its populated?

kami[12:56 PM]
st2api.controllers.v1.actionexecutions.py

[12:56]
in post method

[12:56]
# Include additional option(s) for the execution
context = {
're-run': {
'ref': execution_id,
}
}

john.welborn[12:56 PM]
great, thanks

kami[12:56 PM]
and also in aliasexecution for executions triggered via chatops / aliases

[12:56]
np

[12:57]
the change should be simple, but we do need to understand the use case and decide how to deal with system /r eserved parameters

[12:57]
perhaps just take base context from user, if provided and then we overwrite attributes if already present

[12:59]
but yeah if you have a good use case please open an issue, etc and i'm sure we can figure something out 🙂

john.welborn[1:00 PM]
sanity check this for me? I have a command line client that submits a request to a service I wrote that handles some more complex policies that will reject requests when necessary. The service then requests executions from st2. Currently chatops is directly from slack to st2 without using my service so I want to have an st2 action called by chatops that will submit the request to the service for possible denial. So I need a way to have the service pass in context so I can continue to use the same action we wrote to make use of it. (Or I could just pass in the context values as options instead)

[1:01]
Or I should (sooner rather than later) write a hubot plugin that sends directly to the service

kami[1:02 PM]
i see, so yeah in this case it sounds like you will need to make modifications to hubot plugin

[1:02]
and st2 api (executions and alias execution api)

john.welborn[1:03 PM]
should I just not use context to pass the channel and user information to a workflow?

kami[1:15 PM]
you can, yes

[1:15]
if you get all the info you need from hubot then yeah you can create context in your service and pass it to st2 api

[1:15]

• the st2 api changes

[1:15]
in any case, i do see value in allowing user to specify arbitrary context inside the execution

john.welborn[1:16 PM]
ok, thanks for the help, I'll look at my options and work on creating the issue

kami[1:16 PM]
np

john.welborn[2:19 PM]
@kami For my needs I think I will just pass in the api_user and source_channel as env instead of setting the context

kami[2:20 PM]
yeah, this should work as well. it would still be good to open a ticket though if you get a chance, for user supplied context that is

[2:20]
but i assume you also want api_user to be dynamic aka not always the same?

john.welborn[2:22 PM]
my service is using the api key for the given user it is submitting the execution for, so I think that value is already fine

[2:23]
sec, looking at that again

[2:26]
ok, api_user is not set and I'm using 'user' in the context instead, but yes, I'd want to pass the value of api_user with each api call

[2:26]
from chatops, api_user gives me the name of the user on slack

[2:26]
so I can @ them back

kami[2:40 PM]
@john.welborn ah, ok in this case it should be fine yeah, if you are using api key per user

[2:41]
as far as api_user goes, would need to dig in and confirm again

[2:41]
since there were some changes in flight for that

john.welborn[2:41 PM]
I would not want to open a way to impersonate

kami[2:50 PM]
so api_user and user would be fixed aka static?

[2:50]
if so then the env variable approach would work

john.welborn[2:55 PM]
per execution, yes

[2:55]
just noticed that env is not an available input/parameters on workflows

[2:56]
can't pass it to context either: Invalid input [name=redact.workflow_status.main, class=DirectWorkflowSpec, unexpected=[u'api_user', u'source_channel']]

[2:58]
showing as context = {"source_channel":"redact","api_user":"johnwelborn"} in the st2 ui

Start in st2api.controllers.v1.actionexecutions.py, specifically the post method where execution context is populated, then inspect aliasexecution for chatops and alias-triggered executions. Define how API callers can supply arbitrary context such as api_user and source_channel while preventing system or reserved attributes from being overridden; done means the supported context is available to workflows through both relevant execution paths.