[openstack-dev] [mistral] [heat] Mistral Workflow resource type - resource signal handling

ELISHA, Moshe (Moshe) moshe.elisha at alcatel-lucent.com
Thu Oct 8 17:27:03 UTC 2015


Hi,

I would like to propose a change in the behavior of the OS::Mistral::Workflow resource signal.

CURRENT:
The OS::Mistral::Workflow resource type is expecting the following request body on resource signal request:

{
  "input": {
    ...
  },
  "params": {
    ...
  }
}

The input section is optional and if exists it will be passed to the workflow execution as inputs
The params section is also optional and if exists it will be passed to the workflow execution as parameters.

The problem this approach creates is that external systems many times send a predefined body that you cannot control and it is obviously not in the format the resource is expecting.
So you basically have no way to pass the information from the request body to the workflow execution.


SUGGESTION:
OS::Mistral::Workflow will treat the root of the JSON request body as input parameters.
That way you will be able to use external systems by making sure your WF inputs are aligned with what the external system sends.

For example, if you try to put the WF alarm_url as a Ceilometer alarm action - Ceilometer will send a request similar to:

{
     "severity": "low",
     "alarm_name": "my-alarm",
     "current": "insufficient data",
     "alarm_id": "895fe8c8-3a6e-48bf-b557-eede3e7f4bbd",
     "reason": "1 datapoints are unknown",
     "reason_data": {
           "count": 1,
           "most_recent": null,
           "type": "threshold",
           "disposition": "unknown"
     },
     "previous": "ok"
}

The WF could get this info as input if it will be defined like so:

  my_workflow:
    type: OS::Mistral::Workflow
    properties:
      input:
        current: !!null
        alarm_id: !!null
        reason: !!null
        previous: !!null
        severity: !!null
        alarm_name: !!null
        reason_data: !!null


The (least used) "params" section can be passed in an custom HTTP header and the OS::Mistral::Workflow will read those from the header and pass it to the WF execution.
Remember, we are trying to solve the problem where you can't influence the request format - so in any case the signal will not get the params in the request body.
If the WF of the user must receive params, the user will always be able to create a wrapper WF with only inputs that starts the orig WF with inputs and params.

In order to make this non-backward compatible change, I suggest to add a property "params_alarm_http_header_name" to the OS::Mistral::Workflow. If null the params are expected to be in the body as today.
If not null - the request should have a header with that name and the value will be a string representing a JSON dict.

I would really like to hear your opinion and comments.

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151008/789d1d93/attachment.html>


More information about the OpenStack-dev mailing list