Remove Cluster class

[magniloquency]

Summary

• Removes the Cluster class (multiprocessing.Process wrapping FixedNativeWorkerAdapter) and its associated ClusterConfig, eliminating an unnecessary intermediate subprocess layer
• SchedulerClusterCombo, tests, and examples updated to use FixedNativeWorkerAdapter directly; workers are now direct children of the combo process instead of grandchildren
• scaler_cluster entry point and run_cluster.py preserved for backwards compatibility, redirecting to the fixed native worker adapter; --num-of-workers accepted as an alias for --max-workers
• SIGINT/SIGTERM handling added to the fixed native adapter entry point
• ECS adapter updated to use scaler_cluster with corrected parameters (--max-workers replaces --num-of-workers/--worker-names; worker IDs are no longer pre-announced since workers self-assign UUIDs)
  • Even before, the cluster did not use the worker names to actually name the workers, and only used the list to control the number of workers spawned
• Documentation updated: removed stale ClusterProcess/Worker[N] startup log output from quickstart, updated --num-of-workers references to canonical --max-workers, and corrected the Fixed Native adapter description

Breaking Changes

• --worker-names CLI flag dropped: The scaler_cluster entry point no longer accepts --worker-names. Passing it will now result in an unrecognized argument error. This flag was previously accepted but had no effect on actual worker naming (workers were identified by generated IDs regardless). Users relying on it should simply remove it from their invocations.
• Cluster and ClusterConfig removed from public API: from scaler import Cluster and from scaler.config.section.cluster import ClusterConfig will no longer work. Use FixedNativeWorkerAdapter and FixedNativeWorkerAdapterConfig directly.

ECS adapter: worker_ids removal

The old ECS adapter pre-announced worker IDs in the StartWorkerGroup response by generating random names (ECS|{uuid}) and computing IDs from them. However, ECS workers self-assign their own UUIDs on connect and are never told what names to use, so the pre-announced IDs never matched any real worker in the scheduler's information_snapshot. As a result, the scheduler's load-based group selection on shutdown (which sums queued_tasks across the group's worker IDs) always saw 0 tasks per group, making group selection arbitrary regardless.

Sending worker_ids=[] is functionally equivalent for all three scaling policies (vanilla, fixed_elastic, capability_scaling). For CapabilityScalingController it is slightly more correct: workers_in_group = 0 accurately reflects that no phantom workers are subtracted from remaining_worker_count when evaluating shutdown safety guards. The underlying limitation — that the ECS adapter cannot do per-group load-informed shutdown selection — is inherent to the architecture and pre-dates this PR.

Fixed native vs native

The fixed native (FN) and native adapters are quite similar, except that the FN adapter always spawns a fixed number of workers and does not support any API for scaling. I think that this makes the FN adapter incompatible with scaling controllers (managers?), and it also means that the FN entrypoint needs extra signal handling logic.

We could refactor the FN adapter to be more similar to the native adapter, however we have already discussed merging the two into one, and so I will refrain from this knowing that the FN adapter is likely to be replaced soon

[sharpener6]

--worker-names was for cluster to separate different clusters, let's say you started 2 clusters of workers locally and connect to scheduler, on scaler_top you can easily look at which worker of cluster it connects to, did you tested this will work with multiple native fixed cluster on same machine?

[magniloquency]

@sharpener6, the worker names aren't actually used for anything other than computing the # of workers. I'm not sure if that was intended, but this PR doesn't lose any behavior: https://github.com/search?q=repo%3Afinos%2Fopengris-scaler+worker_names+path%3A%2F%5Esrc%5C%2Fscaler%5C%2Fcluster%5C%2Fcluster.py%2F&type=code