Daniel Hilst
8f90c68c82
Two gaps in what the wire suite proves, both about traceability rather than about a new behaviour. S-31 had no wire case. A node whose chain.currstate is "boot" has an operating system and must be left to start it; a node handed a netboot script every time it powers on reinstalls itself forever, and does so silently, because each individual boot looks like a successful one. The Kea side of this is covered by dhcp_kea_plugin_intent.t, but the ISC side is built inline in addnode against a live database and cannot be reached by a unit test at all. The new case asks twice with the same MAC: once as firmware with no user class, once announcing the xNBA user class the first stage sets. Only the second request can be answered with the node's script, so only the second request can see the bug. What is asserted is S-31's own wording -- not "no boot file", which would forbid the stage-1 binary a server is entitled to send, but "not the node's xNBA script". The node is defined with netboot=xnba because only that method generates a second stage. The remaining ten scenarios already proven on the wire now say which specification scenario they prove, in the same "S-nn:" form the rest of the suite uses. That raises the scenarios cited by a wire case from 36 to 47 of the spec's 73, without running anything new -- the coverage was there and was not traceable.
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!