Resource Requirement minmax validation

[aldbr]

A job containing a Workflow (with or without steps) should have valid ResourceRequirement.

• Return an error if the ResourceRequirement minmax is invalid (min > max):
  - should be managed by cwltool / cwl-utils
• Return an error if there's a ResourceRequirement requirements in a Production workflow
• Add unit tests with examples

Linked to: common-workflow-language/cwltool#2163

[Stellatsuu]

I've looked at the CWL Documentation and I've seen that :

• A Workflow can have a list of requirements, such as :

cwlVersion: v1.2
class: Workflow

requirements:
...

• A Workflow can have multiple WorkflowStep, and every WorkflowStep can have a list of requirements, such as :

cwlVersion: v1.2
class: Workflow

steps:
    step_1:
          requirements:. ...
    step_2:
          requirements: ...
...

• A WorkflowStep can have a run attribute, containing either a CommandLineTool, a Workflow or an ExpressionTool, which can have a list of requirements, such as :

cwlVersion: v1.2
class: Workflow

steps:
    step_1:
          run:
              class: CommandLineTool
              requirements: ...
 ...
...

I have some cases I'm not sure of, such as :

A case where the Workflow has requirements and his steps requirements in their run attribute
cwlVersion: v1.2
class: Workflow
requirements: ...

steps:
    step_1:
          run:
              class: CommandLineTool
              requirements: ...
 ...
...

A case where the WorkflowStep has requirements and his run attribute also has requirements
cwlVersion: v1.2
class: Workflow

steps:
    step_1:
    requirements: ...
          run:
              class: CommandLineTool
              requirements: ...
 ...
...

A case combining all three
cwlVersion: v1.2
class: Workflow
requirements: ...

steps:
    step_1:
    requirements: ...
          run:
              class: CommandLineTool
              requirements: ...
 ...
...

Are there any other use cases I should be aware of? I'm not entirely sure what kind of error I need to implement here since some parts of the documentation seem to be missing (if we're following it). I'm not fully clear on the specific use case, and I want to avoid any misunderstandings. Could you help clarify this a bit, @aldbr?

[mexanick]

@Stellatsuu step and run requirements seem to be the complimentary ways of specifying the same. Under both step and run, requirements is an optional field. run is, on the other hand, a mandatory one. It should be verified, but I think CWL parser will combine the step requirements specified directly under step and under step/run.
Now, it seems that @aldbr would like to forbid any step-level requirements in case Workflow-level requirements are present. @aldbr is it what you want? If yes, why? Of course, conflicting requirements should lead to an error, but why would we want to forbid some scope-narrowing requirements?

[aldbr]

Could you help clarify this a bit, @aldbr?

Sure @Stellatsuu, sorry this was not super clear...

A job can be a CommandLineTools or a Workflow, and can also be a nested Workflow.
But it is executed on a single worker node (that might contain multiple cores though).
Therefore, only the global requirements should be taken into account for scheduling the job and controlling its cpu/ram consumption with cgroups.

Now, it seems that @aldbr would like to forbid any step-level requirements in case Workflow-level requirements are present. @aldbr is it what you want? If yes, why? Of course, conflicting requirements should lead to an error, but why would we want to forbid some scope-narrowing requirements?

Indeed you're right actually, we should allow the scope-narrowing requirements, but we would need to make sure that:

• cwltool can identify whether a step/run requirements is not larger than the global requirements.
• if it's not the case, then dirac (the prototype) should do it.

In any case, it's best if it is checked when it goes through the service, here: https://github.com/aldbr/dirac-cwl-proto/blob/0a7ab0154feadd641e17fdcabf3f0b83105fd4df/src/dirac_cwl_proto/job/__init__.py#L231
So that the service returns an error to the user before trying to execute it.

You can just try running a workflow with run requirements bigger than global requirements and see whether it works and if you get an error.
If it's the case, then we are fine, and you can just add a unit test with the workflow to make sure we don't break anything later on.

Thanks!

[mexanick]

Normally, CWL runner internally checks if the requirements can be satisfied and errors out if it is not possible. This means, narrowing requirements are possible, but conflicting are obviously not.

[Stellatsuu]

Thank you both for your responses.

Therefore, only the global requirements should be taken into account for scheduling the job and controlling its cpu/ram consumption with cgroups.

Are you talking about ResourceRequirement here? If yes, can't we have a global ResourceRequirement and some more specific ResourceRequirement in steps? I've seen this in cwltool tests CWLs:

cwlVersion: v1.2
class: Workflow
requirements: 
    ResourceRequirement:
        coresMin: 4
        coresMax: 4

steps:
    step_1:
             requirements: 
                      ResourceRequirement:
                          coresMin: 1
                          coresMax: 1

identify whether a step/run requirements is not larger than the global requirements.

What do you mean by that ? Because we could have a step that has more specific requirements than the global Workflow, right ? For example :

cwlVersion: v1.2
class: Workflow
requirements: DockerRequirement

steps:
    step_1:
             requirements: 
                      InlineJavascriptRequirement: ...
                      ShellCommandRequirement: ...

In this case, the step has 3 requirements (1 global and 2 specific) and the Workflow only has one