mirror of
https://github.com/xcat2/xcat-core.git
synced 2026-10-07 10:06:39 +00:00
Daniel Hilst
05185b13db
The wire suite compared the two backends against xCAT-test/dhcptest/spec.md and found four places where a node was told different things depending on which daemon answered. Each is fixed at the side the spec calls correct. Option 12 (S-35): Kea builds the host-name option out of a reservation's single `hostname` field and runs it through ddns-qualifying-suffix on the way out, so a node asking who it was got "node01.cluster.example.com" while ISC, which writes option 12 and the DDNS name from separate statements, said "node01". A name that already ends in a dot is fully qualified and is not qualified again, so the reservation is now written "node01." -- the wire agrees with ISC, and the suffix still qualifies the dynamic clients that have no reservation. A reservation's option-data cannot be used for this: processHostnameOption adds option 12 before appendRequestedOptions runs, and appendRequestedOptions only fills in options that are not already present. Reservation lookups are made dot-insensitive so `makedhcp -d` and `-q` keep matching a node by its bare name. Option 43 / ISAN (S-20): Kea appends an encapsulated space to a reply only when the option that carries it is configured too, and option 43 is `type: empty` with `encapsulate: isan`. Naming only the isan-space sub-options left them with nothing to travel in and the initiator was offered an address with no target, so the empty container is now named alongside them. ISC needs no equivalent -- declaring `option isan.iqn` builds option 43 for it. Boot file fallback (S-12): dropping an architecture branch from the ISC if/else chain let that client fall through to the final `substring(filename,0,1) = null` catch-all and be handed /yaboot, which is the loader substitution the spec forbids. Suppressed architectures now get an explicit empty branch. Kea cannot have this bug: its classes are independent and xcat-fallback excludes every recognised arch. Reload (S-40): `systemctl reload kea-dhcp4` returns 0 once the signal is delivered, and Kea can then reject the config and keep serving the old one while systemctl still reads active -- a node added by discovery was never adopted. dhcp4 and dhcp6 intents therefore always carry a control-socket, and a reload goes over it so the daemon reports whether it took, falling back to reset-failed + restart when it cannot confirm. The fixture now proves a daemon actually holds port 67 before it believes the backend is serving, which is what turned the reload failure from a flake into a reproducible case. Verified on the wire against both backends on EL10 with dhcpd 4.4.3 and kea 3.0.3: all ten cases rc=0 on each. Unit suite 848/848.