The backoff that decides when to re-fork the install monitor is arithmetic over a handful of counters, but it lives inline in xcatd among the daemon's globals, its signal handlers and its fork. xcatd needs the database, SSL, the plugin tree and /var/run/xcat before it will run, so nothing in a unit test can execute that arithmetic; a test can only match patterns against the script's source and hope the shape it finds behaves. That is how a retry budget which ran out and could never be refilled passed a green test run. Move the pacing to xCAT::RespawnUtils as pure functions: each takes the current state and the current time and returns the next state, reading no clock, no globals and no files. Passing the time in is what makes the schedule checkable over a virtual clock instead of in real seconds, and returning a new state rather than mutating one is what makes it safe to call from the SIGCHLD handler -- the result is built before the caller installs it, so a signal arriving partway through cannot leave the pacing half-updated. The behaviour is unchanged from the previous commit and stays covered by xCAT-test/unit/xcatd_monitor_respawn.t, which now executes these functions instead of grepping for them: the delay doubles from XCATD_MON_RESPAWN_MIN_INTERVAL (5s) to XCATD_MON_RESPAWN_MAX_INTERVAL (300s) and holds there without ever refusing a retry, and a monitor that stayed up XCATD_MON_RESPAWN_HEALTHY seconds (60s) resets the backoff when it later dies. policy() now also refuses a floor below one second, which would double to itself and give a fork storm rather than a backoff, and a ceiling under the floor. Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
xCAT
xCAT is a toolkit for deployment and administration of clusters of all sizes.
The xCAT sunset was only a quick eclipse
Dear xCAT Community,
The xCAT sunset has changed course. VersatusHPC has been invited to join the xCAT Consortium, and future development will move toward direct upstream contributions coordinated with the Consortium and its existing member companies.
That matters most for Enterprise Linux 10 (EL10). EL10 support is coming to xCAT, restoring a future operating-system path for sites that still rely on xCAT. This is an important change from the previous sunset guidance, where the lack of an EL10 path was one of the strongest reasons to move away from xCAT.
The xCAT Consortium continues to recommend Confluent as the long-term successor to xCAT, and that remains the Consortium position. Users planning new cluster-management deployments should evaluate Confluent and its xCAT comparison documentation.
At the same time, xCAT is no longer sunsetted. The Consortium and participating companies will continue updating xCAT while there is community and user demand for it.
In summary:
- xCAT development is continuing upstream through the Consortium and participating companies.
- Enterprise Linux 10 support is coming.
- Confluent remains the Consortium-recommended successor and migration path.
- xCAT updates will continue while there is community and user demand.
We want to thank the xCAT Consortium and community for keeping this project moving. The sun went behind the moon for a moment, but xCAT is still here.
For more information on Confluent and how to get started, please visit the Confluent: Project Page, Documentation or Confluent vs xCAT comparison.
With thanks,
The xCAT Consortium
Documentation
xCAT Documentation is hosted on Read The Docs: https://xcat-docs.readthedocs.io
Status
| xCAT Version | Build Status |
|---|---|
| Latest (master branch) | |
| Stable (latest release) |
Looking for older versions?
Open Source License
xCAT is made available under the EPL license: https://opensource.org/licenses/eclipse-1.0.php
Developers
Want to help? Check out the developers guide!