feat(dask): add nthreads option to dask-worker command

[Alputer]

Following the integration of Dask into REANA and discussions with several REANA users, we identified the need to make the number of threads configurable.

In this commit, we propagate the specified number of threads per worker or the default value to the dask-worker command.

Closes reanahub/reana#874

[tiborsimko]

todo: ‏We may need to sanitize the inputs. E.g. I have passed a non-integer value:

    dask:
      image: docker.io/coffeateam/coffea-dask-cc7:0.7.22-py3.10-g7f049
      single_worker_number_of_threads: 4.5

and the workflow was accepted for execution. (Perhaps we could verify integer-ness of the value already in the client, as the first line of defense. But we should also be sanitising on the server-side as well.)

The pod was obviously not starting due to:

$ k logs reana-run-dask-916d3266-default-worker-aa138e6474-5dc87954ngqzx
Usage: dask-worker [OPTIONS] [SCHEDULER] [PRELOAD_ARGV]...
Try 'dask-worker --help' for help.

Error: Invalid value for '--nthreads': '4.5' is not a valid integer.

And the pod went into a crash loop:

$ k get pods | grep -E '(NAME|aa13)'
NAME                                                              READY   STATUS             RESTARTS        AGE
reana-run-dask-916d3266-default-worker-aa138e6474-5dc87954ngqzx   0/1     CrashLoopBackOff   5 (2m12s ago)   4m58s

And the user would see the workflow as running:

$ rcg list
NAME                            RUN_NUMBER   CREATED               STARTED               ENDED                 STATUS
threads-45                      1            2025-02-20T13:13:10   2025-02-20T13:13:22   -                     running

Dunno when it would eventually stop, but we should exit early in these error situations.

Can you please round to the nearest integer on the server-side? And, whilst fixing this concrete usage scenario, can you please check also similar bordeline situations when a user passes an invalid container image or an invalid memory value?

[Alputer]

I added a check in reana-commons to prevent users from providing non-integer values. Since the OpenAPI specification in reana_analysis_schema.json already allows validation through type and regex, and considering they are enough to cover the basic checks, I guess it is sufficient, and we may not need additional checks beyond the initial reana.yaml validation.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 73.20%. Comparing base (e4a64d8) to head (eaf2b59).
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #636      +/-   ##
==========================================
+ Coverage   73.16%   73.20%   +0.04%     
==========================================
  Files          17       17              
  Lines        1986     1989       +3     
==========================================
+ Hits         1453     1456       +3     
  Misses        533      533              

Files with missing lines	Coverage Δ
reana_workflow_controller/config.py	94.51% <100.00%> (+0.06%)	⬆️
reana_workflow_controller/dask.py	56.09% <100.00%> (+0.17%)	⬆️
reana_workflow_controller/workflow_run_manager.py	80.16% <ø> (ø)

[tiborsimko]

Works nicely 👍