2
0
mirror of https://github.com/xcat2/xcat-core.git synced 2026-10-22 07:38:08 +00:00
Daniel Hilst f2112dcafa test(dhcptest): drive xCAT-generated DHCP config from the wire
dhcptest could already assert on what a server puts on the wire, but on a
single-node management node -- the CI runner above all -- there was nothing
for it to talk to, so a wire case would have passed while proving nothing.

dhcpfixture.sh builds the missing network out of a veth pair: the server end
carries the management address and is the only interface named in
site.dhcpinterfaces, the client end has no address, which is the state a
provisioning NIC is in when a machine boots on it. It then defines a network
with a dynamic range and one node with a MAC, runs makedhcp so the
configuration comes from xCAT rather than from hand-editing, and restores
everything from a trap. All the xCAT knowledge lives there, next to the
xcattest cases, so dhcptest itself stays agnostic to it.

The new scenarios assert what a provisioning server has to get right:

  provision-vs-discovery.conf    a known machine gets its reservation and its
                                 own loader, an unknown one gets a pool address
  discovery-bootfile.conf        an unknown machine is told what to boot too
  node-specific-second-stage.conf  the chainloaded stage names its host
  hierarchy-dhcpserver.conf      a subnet whose pool was handed to another
                                 server ignores unknown MACs but still points
                                 known ones at it

Those are four files rather than four scenarios in one because they describe
server configurations that contradict each other, and because --set values are
resolved when a file is loaded, before -s selects anything: an unused
scenario's missing variable would otherwise abort a run that never intended to
use it. ISC dhcpd leaving the unknown-client boot file to the per-host blocks
while Kea puts it on the subnet is exactly such a contradiction, which is why
discovery-bootfile.conf is opt-in and the fixture only asks for it on Kea.

dhcptest_backend_switch reruns the same files after switching site.dhcpbackend
and regenerating, so the backend-agnosticism the tool exists to demonstrate is
itself under test rather than asserted in a comment.

The `in` operator now accepts an inclusive first-last range as well as a CIDR
and a list: a dynamic pool is written as two addresses because it rarely lines
up on a prefix boundary.

Verified against a real dnsmasq in a network namespace: 17/17, 3/3 and 5/5
assertions green, a deliberately wrong expectation failing with expected and
received on one screen, and host networking untouched.

Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
2026-09-10 08:51:10 -03:00
2024-05-07 16:43:07 +02:00
2018-11-28 10:28:17 +08:00
2021-04-05 09:34:37 -04:00
2018-02-09 01:03:46 -05:00
2024-04-20 02:18:05 +02:00
2026-04-17 03:14:04 -03:00

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) Documentation Status
Stable (latest release) Documentation Status

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!

S
Description
No description provided
Readme EPL-1.0 231 MiB
Languages
Perl 75.5%
Shell 12.8%
JavaScript 5.6%
Python 2.5%
Go Template 2.2%
Other 1%