Override runtime parameters at runtime

Is there a way to override runtime parameters at runtime, except for explicitly porting them from the inputs?

eg:

{ "myWorkflow.myTask.runtime.disks": "100 GB" }

Or if I did explicitly port them, does (/ should) a value of None in the runtime be override by a backend’s default.

[illusional]

Can I suggest Specifying / overriding runtime attributes from JSON as a feature to be added to the openwdl spec. Something similar to Specifying Workflow Inputs in JSON, and would follow the same resolution order as #141 proposes (backed up by https://github.com/broadinstitute/cromwell/issues/2446).

Maybe something like:

---

Specifying / overriding runtime attributes from JSON

Workflow runtime attributes may additionally be specified as key/value pairs within the JSON input. The mapping from JSON or YAML values to WDL values is codified codified similar to the serialization of task inputs section.

In JSON, the user may be able to specify task-specific runtime attributes similar to the following:

{
  "wf.t1.runtime.memory": "16 GB",
  "wf.t2.runtime.cpu": 2,
  "wf.t2.runtime.disks": "100 GB",
  "wf.t3.runtime.arbitrary_key": ["arbitrary", "value"]
}

As the runtime section consists of key/value pairs, it’s up to user to ensure they provide the correct coercible type for the backend they are targeting. See the section on Type Coercion for more details.

Resolution Order

Similar to how inputs are resolved, these runtime parameters are resolved in the following order:

1. Inputs provided by the inputs JSON
2. The value provided inline on the task, whether that’s an expression or literal value.

Edit: cpus to cpu, because the latter is a recognised keyword.

[geoffjentry]

@illusional One of the many, many, many issues I have with runtime is that there’s no way to officially do this. It’s possible to wire in an input there as any valid WDL expression is viable there, but that requires the WDL to be written that way. You can’t do it the way you’re suggesting.

One of the other many, many, many issues I have with this is that not everyone sees the current situation as bad 😃

I’d personally wholeheartedly support suggested changes to the spec which start to overhaul runtime