It was reported by a user that in orquesta workflows (and potentially other actions that call additional actions: I.E. Mistral and action-chain) actions do not render with the correct config_context. Instead nested actions use the parent context of the original workflow.
For example: If you have the actions Pack1.Workflow1 and Pack2.Action1 and Pack1.Workflow1 makes a call to Pack2.Action1 the config_context of Pack1 will be used instead of the config_context of Pack2.
Using the packs at bigmstone/packConfig I can reproduce this issue with the following output:
(virtualenv) vagrant@ubuntu-xenial:~/local/st2$ st2 run pack2.action1
.
id: 5c75a3a4076129162e84b4ef
status: succeeded
parameters:
value1: test
result:
exit_code: 0
result:
context_value: test
stderr: ''
stdout: ''
(virtualenv) vagrant@ubuntu-xenial:~/local/st2$ st2 run pack1.workflow1
.
id: 5c75a2d5076129162e84b4ec
action.ref: pack1.workflow1
parameters: None
status: failed
start_timestamp: Tue, 26 Feb 2019 20:34:29 UTC
end_timestamp: Tue, 26 Feb 2019 20:34:30 UTC
result:
errors:
- message: 'ParamException: Failed to render parameter "value1": ''dict object'' has no attribute ''config_item_one'''
task_id: task1
type: error
output: null
md5-45231deda8c346b135c7e0fbcba41152
(virtualenv) vagrant@ubuntu-xenial:~/local/st2$ st2 run pack1.workflow2
.
id: 5c75a84b0761291a45a8de5c
action.ref: pack1.workflow2
parameters: None
status: succeeded
result_task: task1
result:
exit_code: 0
result:
context_value: test
stderr: ''
stdout: ''
start_timestamp: Tue, 26 Feb 2019 20:57:47 UTC
end_timestamp: Tue, 26 Feb 2019 20:57:48 UTC
+--------------------------+------------------------+-------+---------------+-------------------------------+
| id | status | task | action | start_timestamp |
+--------------------------+------------------------+-------+---------------+-------------------------------+
| 5c75a84b07612919e4b86d54 | succeeded (0s elapsed) | task1 | pack2.action1 | Tue, 26 Feb 2019 20:57:47 UTC |
+--------------------------+------------------------+-------+---------------+-------------------------------+
From a brief glance it looks like we do not update config context again in workflow engine. I have not tested this in mistral, but I would assume it does not affect mistral since st2 actions are run via API and build up their own context on execution.
@bigmstone Can we put @jinpingh on this?
Most helpful comment
@bigmstone Can we put @jinpingh on this?