cli: addition of parameters in workflow_start()

[dinosk]

• ADD arbitrary number of parameters in workflow_start().

• Updates the reana-server openapi spec with parameters in
  set_workflow_status, and the status passed in the query instead of
  the request body.

Connects #21
Closes #143

Signed-off-by: Dinos Kousidis dinos.kousidis@cern.ch

[dinosk]

To test running a workflow without caching: reana-client start CACHING=false

[diegodelemos]

Is this schema being used? I just see a free dict here:

    parsed_parameters = {'parameters':
                         dict(p.split('=') for p in parameters)}

If this is the desired schema, we have to think exactly where we want each parameter to end up and not mix responsibilities. As I see in RWES PR, this parameters are not just "parameters", they are "workflow_engine_parameters" as in cwltool could be the --timestamps flag (what I guess run_parameters means) but they are passed as workflow parameters.

If we want also the "workflow_parameters" (i.e. in demo root6-roofit events) (what I guess input_parameters are) to be overwritten by this call, then we have to update the database since they are written to the DB at creation time.

In any case they are two different things we should differentiate. To keep it simple, it the PUT /api/workflows/{workflow_id_or_name}/status I would for now, only pass "workflow_engine_parameters" and add a new parameter to the Celery task and this one would be the one representing workflow engine parameters.

[dinosk]

The schema needs updating, regarding the differentiation I can see input parameters (number of events for example) and workflow run parameters (caching true|false), the schema was created with these 2 types, but I went with a single dictionary for now, to keep it short.
We should ticketize this splitting parameters into 2, but since now only the CACHING=true|false is read from them we can use it as is.

[diegodelemos]

Makes sense 👍 . So for now we implement this just with workflow engine parameters and we add this additional parameter in the task (engine_parameters or similar). Later we think about how we want to handle the workflow_parameters (I will create issue from this discussion).

I would emphasize in those two names or similar since: one, the workflow_parameters is as we have modeled it (or input_parameters as it is common terminology in yadage and CWL), and second the workflow engine parameters (related to reanahub/reana#73 (comment) dicussion), since they are literally parameters for the concrete workflow engine implementation (i.e. cwltool ones or yadage ones).