Fix worker count calculation to return at least one worker on single-CPU hosts

[coderabbitai]

Problem

The _get_num_workers() method in components/clp-package-utils/clp_package_utils/controller.py currently returns multiprocessing.cpu_count() // 2, which evaluates to 0 on single-CPU hosts. This would prevent workers from starting properly.

Location

components/clp-package-utils/clp_package_utils/controller.py, lines 791-797 (as of PR #1502)

Impact

On systems with a single CPU core, no workers would be started, causing CLP components to fail.

Solution

Ensure the method returns at least 1 worker by flooring the result to a minimum of 1.

References

• Original discussion: feat(deployment): Add --setup-only flag to start-clp.sh to set up the package without starting components (resolves #1475). #1502 (comment)
• PR feat(deployment): Add --setup-only flag to start-clp.sh to set up the package without starting components (resolves #1475). #1502: feat(deployment): Add --setup-only flag to start-clp.sh to set up the package without starting components (resolves #1475). #1502
• Requested by: @junhaoliao

[junhaoliao]

at the moment, a concurrency count of 0 appears to be harmless because

celery falls back to the number of processors available when the specified --concurrency is 0: https://github.com/celery/celery/blob/2aebae52ebc9b5156faa040fe957fb8ef5421556/celery/bin/worker.py#L194-L204

and

our reducer rounds the number to 1 if the specified --concurrency is less than 1:

clp/components/job-orchestration/job_orchestration/reducer/reducer.py

Line 68 in 2ac456e

concurrency = max(int(parsed_args.concurrency), 1)

that said, passing a concurrency count of 0 to workers is quite fragile as the worker's handling may subject to change. we should still fixing the rounding then