Daniel Hilst
279207cf0a
A compute node that boots the legacy Genesis image on el10 x86_64 never acquires an address. Its serial console reports "/usr/bin/doxcat: line 293: dhclient: command not found" and then "It seems to be taking a while to acquire an IPv4 address". The DHCP server side is sound: Kea leases the address and the node never asks for it. AlmaLinux 10 and EPEL 10 package no ISC dhcp-client. dracut_install reports a missing binary and returns, so module-setup.sh named dhclient, the build kept going and the image shipped without a client. doxcat then named dhclient at six call sites with no alternative. doxcat now chooses its client at run time. genesis_dhcp_command() returns the command line for one interface and one address family, and genesis_start_dhcp() runs it and reports when the image carries none. The ISC client keeps its command line where a release packages it, so el8 and el9 are unchanged. Where it is absent, dhcpcd stands in: AlmaLinux 10 baseos packages it at 236 KB, and it carries its own resolv.conf, hostname and ntp hooks, so it needs no dhclient-script. dhcpcd on a single interface exits when its 30 second timeout expires and de-configures the interface as it goes, so it is asked for -t 0 and -p. The dracut module installs whichever client the build root carries, together with the hooks dhcpcd runs on every lease. The spec build-requires dhcpcd from rhel 10 on, and verify-genesis-payload now requires usr/sbin/dhcpcd there, so an image that ships with no client fails the build instead of reaching a node. genesis_dhcp_client.t drives both routines with the clients shadowed by recording stubs. It fails on the parent commit, and deleting the dhcpcd branch turns five of its assertions red. Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com> (cherry picked from commit b9329998c80383bb0397d16a558f66a6bb9db399)
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!