chenghuichen opened a new pull request, #3698:
URL: https://github.com/apache/celeborn/pull/3698
<!--
Thanks for sending a pull request! Here are some tips for you:
- Make sure the PR title start w/ a JIRA ticket, e.g. '[CELEBORN-XXXX]
Your PR title ...'.
- Be sure to keep the PR description updated to reflect all changes.
- Please write your PR title to summarize what this PR proposes.
- If possible, provide a concise example to reproduce the issue for a
faster review.
-->
### What changes were proposed in this pull request?
Add `celeborn.worker.decommission.shutdown.enabled` configuration. When set
to true, the worker will walk the decommission path (send
`ReportWorkerDecommission` to master, wait for all shuffle data to be consumed
or expired) upon receiving SIGTERM, instead of the graceful shutdown path.
When enabled, this overrides `celeborn.worker.graceful.shutdown.enabled`.
The shutdown hook timeout is also extended to
`celeborn.worker.decommission.forceExitTimeout` to match the decommission wait
window.
### Why are the changes needed?
In scheduled auto-scaling scenarios (e.g., scale up at peak hours, scale
down at off-peak), operators want to simply shrink the node pool and let the
PaaS layer send SIGTERM without writing custom preStop scripts or manually
invoking the decommission REST API.
The existing graceful shutdown
(`celeborn.worker.graceful.shutdown.enabled=true`) is designed for rolling
upgrades. For permanent scale-down, the correct semantic is decommission.
Previously this could only be triggered via REST API or master-pushed events,
requiring additional scripting in the teardown workflow.
With this change, operators only need to set one config and align
`celeborn.worker.decommission.forceExitTimeout` with the pod's
`terminationGracePeriodSeconds`.
### Does this PR resolve a correctness bug?
<!-- Check if yes. The `correctness` label will be added/removed
automatically. -->
- [ ] Yes
### Does this PR introduce _any_ user-facing change?
<!-- Check if yes. -->
- [x] Yes
### How was this patch tested?
- Verified default behavior unchanged (config defaults to false, existing
graceful shutdown unaffected)
- Verified that when enabled, `WorkerStatusManager.exitEventType` is set to
`Decommission` and `workerGracefulShutdown` returns false (suppressing recovery
DB initialization)
- Verified shutdown hook extends timeout to `decommission.forceExitTimeout`
before calling `decommissionWorker()`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
