Daniel Hilst
ba469ecfe7
Which DHCP backend a management node runs is an implementation default of its distro -- kea on the newer releases, isc on the older ones -- so a node booting on the same network has to be told the same things either way. Until now CI exercised whichever backend the runner happened to configure, which proves half of that and hides every drift between the two. The wire cases now carry a dhcp_wire label, and the CI driver holds them back from the main pass: it asks dhcpfixture.sh which backends are installed, then runs the whole set against one and again against the other. Each pass is bracketed by backend-setup, which points site.dhcpbackend at the backend and stops the other daemon -- two servers on one wire both answer the same DISCOVER -- and backend-teardown, which restores the site table and restarts what was running before. Running every case under one backend and then every case under the other, rather than switching inside each case, reconfigures the daemon once per pass instead of once per case, and gives each failure in the summary the backend name it belongs to. The summary counts case runs rather than cases, since a wire case is run once per backend. The check gate is relaxed from [ -x ] to [ -f ]: the fixture invokes dhcptest as `python3 src/dhcptest`, so the execute bit only matters to someone running it directly, and testing it made every wire case skip on Debian. dhcptest_backend_switch is dropped, along with the fixture's backend and alt-backend actions: with every case running under both backends there is nothing left for a case that switches one.
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!