> On 08 Oct 2015, at 23:27, ELISHA, Moshe (Moshe)
> wrote:
>
> 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.
That makes sense to me, I’m just wondering if it’s possible to have a
transformer somewhere that would convert data to a needed form. I’m not that
good at Heat though.
> 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.
I’m generally ok with this suggestion. My only concern is that we won’t be able
to trigger the same WF with different type of triggers. For instance, I want to
have a WF that does healing but I want to have Ceilometer alarm and some other
type of trigger (e.g. some monitoring system like Zabbix) to trigger this WF.
Most likely it would not be straightforward because I’d have to design my WF
for a certain triggering systems: its input values should match request body
structure sent by a trigger.
At the same time, this is probably going to be a rare situation when we need
two types of triggers. And like you said we can always create a wrapper
workflow, if needed for other types of triggers. General approach here actually
may be: we create a WF with input structure that’s most convenient from WF
standpoint itself and for every type of trigger we create a wrapper WF, if
needed.
> 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.
Sounds ok to me.
Renat Akhmerov
@ Mirantis Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
