input of workflow-get API is ambiguous

[Moshe Elisha]

The input field returned by the workflow-get definition is a string in a certain format that can be read in different ways.

Consider the following two input sections:

  input:
    - first
    - second: "value, third"

and:

  input:
    - first
    - second: "value"
    - third

In both cases the "input" field will be "first, second=value, third" - there is no way to distinguish between the input and its default value.

I believe "input" should not be a string but a list.
Each element in the list should be either a string (representing an input with no default value) or a one entry map.

API backward comparability should be considered obviously. Maybe there should be a new field called "input_list" or something.

[Renat Akhmerov (rakhmerov)]

Since this is an obvious bug in the initial design I tend to think we don't need to make a backwards compatible change. Additionally, this "input" field returned by the API is typically used as a hint for a human on what to provide to the workflow when it starts. For making a decision on what should be passed programatically (e.g. to prepare data sets for testing) this info is not enough anyway, it also needs to include at least data types.

So my suggestion is to keep representing "input" as a string but formatted a bit differently, so that the first example above will give:

'first, second="value, third"', so "second" should be represented the same way as it was initially, with quotes.

[Moshe Elisha (melisha)]

Hi,

For the purpose of "hint for a human" I agree but we need this information to programatically process it (we want to validate the inputs/outputs of the workflow).

For that we need that the inputs (and outputs https://blueprints.launchpad.net/mistral/+spec/mistral-workflow-outputs-in-wf-apis) will be exposed in the API and be processed by a program and the best format to do that is JSON as anyway the definition is in YAML.

It might be a separate topic than this bug (maybe add a new "interface" field to "get workflow def" API or it might be done with this bugfix.

[Renat Akhmerov (rakhmerov)]

OK, I see your point. Then yes, we may need a different field for that.

[Moshe Elisha (melisha)]

Thanks. We need something like:

   "input": [
 "my_int_input",
 { "my_bool_input": true },
 {
  "my_json_input": {
   "defaultKey": "defaultValue"
  }
 }
   ]

[Renat Akhmerov (rakhmerov)]

At the moment, I tend to think we need to keep backwards compatibility and add a new field. Maybe one field combining info about both "input" and "output" structures in JSON.

[Moshe Elisha (melisha)]

I agree. In case we are adding a new field, the priority of this bug can be reduced as the needed information will be available without ambiguity in the new field.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/703294

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/703294
Committed: https://git.openstack.org/cgit/openstack/mistral/commit/?id=4a6309683b698dc8ec41955ae1ac77b0200ff6a9
Submitter: Zuul
Branch: master

commit 4a6309683b698dc8ec41955ae1ac77b0200ff6a9
Author: ali <email address hidden>
Date: Sun Jan 19 14:20:51 2020 +0000

    wrapped the value of parameters in inputs(in wf get API) with "".

     the input field of workflow-get API is ambiguous, and not well defined,
     2 different inputs can have the same value for the input field.

     for example :

       input:
         - first
         - second: "value, third"

      and:

        input:
         - first
         - second: "value"
         - third

     for both it was: input ="first, second=value, third"

     now it is:
     for the first: input ="first, second=\"value, third\""
     and for the second: input ="first, second=\"value\", third"

     Closes-Bug: 1631541

    Change-Id: I4b3fc7e0ad4552022d44c3bdd8c87004f5e8ff46
    Signed-off-by: ali <email address hidden>

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/mistral 10.0.0.0b2 development milestone.