Expose scheduler empty-workload propagation in Helm values

[tamarubin]

Problem

We hit a race condition during zero-replica transitions:

• the source workload is updated to replicas=0,
• while in parallel Karmada binding/work reconciliation may treat target changes as orphan cleanup and delete Work,
• resulting in non-deterministic behavior during transitions (Work deleted vs expected zero-replica propagation).

In this scenario we need scheduler support for empty workloads to keep propagation behavior consistent when replicas are zero.

Today the Helm chart does not expose --enable-empty-workload-propagation, so enabling the behavior requires post-deploy patching in infrastructure code (Terraform null_resource + kubectl patch) just to add one scheduler flag.

Why this is painful

• Race amplification: operational recovery from this race depends on external patching instead of a chart value.
• Operational fragility: patch logic is outside Helm and can drift from chart state.
• Upgrade risk: scheduler rollout/upgrade can remove the patched arg until patch logic re-runs.
• Extra permissions/complexity: requires direct API patching and credential plumbing from IaC.
• Harder troubleshooting: desired scheduler behavior is not declarative in Helm values.

Expected

Helm chart should provide a dedicated value, for example:

• scheduler.enableEmptyWorkloadPropagation: false (default)
• when enabled, render --enable-empty-workload-propagation=true in karmada-scheduler command args.

Context

PR with implementation:

• feat: add scheduler empty-workload chart option #7570

If maintainers agree with this direction, we can iterate on naming/defaults as needed.

[zhzhuang-zju]

Thanks for your feedback, will take a look next week

[zhzhuang-zju]

Hi @tamarubin, sorry for the late response.

/kind feature
First, I think this is a reasonable use case. And I'm okay with providing a dedicated value to expose scheduler empty-workload propagation. @tamarubin Are you willing to submit a pr to handle this?
Your issue just made me realize that the Karmada chart supports too few user-configurable command lines. This is a bad experience. We can optimize that as a new capability later. WDYT? @seanlaii @jabellard

[seanlaii]

Your issue just made me realize that the Karmada chart supports too few user-configurable command lines. This is a bad experience. We can optimize that as a new capability later. WDYT? @seanlaii @jabellard

Totally makes sense to me! Thanks for bringing this up.

[jabellard]

Your issue just made me realize that the Karmada chart supports too few user-configurable command lines. This is a bad experience. We can optimize that as a new capability later. WDYT? @seanlaii @jabellard

Totally makes sense to me! Thanks for bringing this up.

+1

[tamarubin]

Thanks for the feedback — this use case makes sense to us as well.
I already opened a PR to add a dedicated Helm value for this:

The PR adds scheduler.enableEmptyWorkloadPropagation (default false) and renders --enable-empty-workload-propagation=true when enabled.

I also updated the PR description with the user-facing release note, following the format in #7457.

For scope, I kept this PR minimal (one dedicated scheduler flag). I agree that broader/flexible chart support for component command-line options (for example extraFlags) would be valuable as a follow-up improvement.

[jabellard]

Thanks for the feedback — this use case makes sense to us as well. I already opened a PR to add a dedicated Helm value for this:

The PR adds scheduler.enableEmptyWorkloadPropagation (default false) and renders --enable-empty-workload-propagation=true when enabled.

I also updated the PR description with the user-facing release note, following the format in #7457.

For scope, I kept this PR minimal (one dedicated scheduler flag). I agree that broader/flexible chart support for component command-line options (for example extraFlags) would be valuable as a follow-up improvement.

Thanks for the awesome contribution and for thinking long term about how we can add more robust support for this class of problem.

I already reviewed. I think we can move forward once @seanlaii and @zhzhuang-zju get a change to take a second look.