fix(dhcp): makedhcp -n fails on a new Kea management node before makedns -n - #7891
Merged
Merged
Conversation
makedhcp -n fails on a new management node that uses the Kea backend:
Error: Unable to find DDNS key material for Kea D2. Run makedns with
dnshandler=ddns first.
xcatconfig writes site.dnshandler=ddns on every new installation, so the Kea
backend asks for the DDNS key, and only makedns -n creates it. No case covers
that order.
kea_makedhcp_without_ddns_key removes both places the Kea backend reads the key
from, runs makedhcp -n, and reads the rendered kea-dhcp4.conf. It then restores
the key material and runs makedhcp -n again, so the case also holds down the
configuration that a management node with a key must keep.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
kea_build_ddns_intent returns an error when no DDNS key material exists, and makedhcp -n reports it instead of configuring Kea. No unit test reads that decision, so the error path and the D2 path are both unmeasured. dhcp_kea_ddns_deferral.t drives kea_build_ddns_intent with and without key material, and drives the sub that attaches the D2 connection to the DHCPv4 and DHCPv6 configurations. It also holds down the two boundaries the change must keep: a management node whose site.dnshandler is not ddns asks for no D2 configuration, and an unreadable networks table stays an error. Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
makedhcp -n fails on a new management node that uses the Kea backend:
Error: Unable to find DDNS key material for Kea D2. Run makedns with
dnshandler=ddns first.
xcatconfig writes site.dnshandler=ddns on every new installation, so
kea_ddns_enabled reports DDNS on, and kea_build_ddns_intent then requires
/etc/xcat/ddns.key. Only makedns -n writes that file. The ISC backend reads no
key, so an ISC management node runs makedhcp -n without one. The Kea backend
plan states that basic DHCP and PXE support must not depend on DDNS.
kea_build_ddns_intent now reports a deferral instead of an error when it finds
no key material. kea_apply_ddns_intent attaches the D2 connection only when a
key exists, and returns the deferral for makedhcp to print as a warning. A
management node with key material gets the same configuration as before.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
kea_makedhcp_without_ddns_key covers the same decision as dhcp_kea_ddns_deferral.t, and no suite runs it: the GitHub workflow runs prove -r xCAT-test/unit, and no CD bundle names the case. Delta debugging at commit scope dropped it. The unit test still fails on the unfixed tree, so the defect stays captured. Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
The comment stated the xcatconfig default and then repeated the reason for the change, which the commit message already carries. Keep the condition only. Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
… key kea_build_ddns_intent returned the deferral under a deferred key. No other xCAT code uses that key: dhcp.pm reports through error, warning, node and data, and makedhcp already passed this message to the callback as a warning. The intent hash now carries the message under warning, so one name describes it from the hash to the callback. Behaviour does not change. Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
viniciusferrao
requested changes
Sep 30, 2026
viniciusferrao
left a comment
viniciusferrao
left a comment
Member
There was a problem hiding this comment.
After running makedhcp -n, makedns -n and makedhcp -a, the DHCP configs still lack dhcp-ddns, and the D2 config is never written.
The -a path applies DDNS settings to fresh intents but saves the previously loaded configs.
We need either complete this transition when the key appears, or have the warning explicitly request rerunning makedhcp -n followed by makedhcp -a after makedns -n.
That should be covered by the recovery sequence in a regression test.
On a new Kea management node, makedhcp -n defers DDNS because no key exists. After makedns -n writes the key, makedhcp -a keeps the DHCPv4 configuration without dhcp-ddns and writes no kea-dhcp-ddns.conf, so DNS updates stay off. The test runs makedhcp -n without a key, adds the key, runs makedhcp -a, and checks the rendered DHCPv4 and D2 configurations. Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
On a new Kea management node, makedhcp -n defers DDNS until makedns -n writes the key. makedhcp -a then applied the D2 settings to the fresh intents, but saved the loaded configurations, which had no dhcp-ddns. It also wrote no kea-dhcp-ddns.conf, so DNS updates stayed off. When DDNS is on and the loaded DHCPv4 configuration has no dhcp-ddns, makedhcp -a now copies the D2 settings into the loaded DHCPv4 and DHCPv6 configurations, writes the D2 configuration and, when enabled, the Control Agent configuration. It then enables and restarts the Kea services. Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
viniciusferrao
self-requested a review
September 30, 2026 19:36
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
makedhcp -nfails on a new management node that uses the Kea backend, untilmakedns -nhasrun:
xcatconfigwritessite.dnshandler=ddnson every new installation, sokea_ddns_enabledindhcp.pmreports DDNS on andkea_build_ddns_intentthen requires the TSIG secret. Onlymakedns -nwrites that secret, to/etc/xcat/ddns.keyand to theomapirow of thepasswdtable. The ISC backend reads no key, so an ISC management node runs
makedhcp -nwithout one. TheKea backend plan states that basic DHCP and PXE support must not depend on DDNS unless a
deployment enables
site.dnshandler=ddns, andxcatconfigenables it for every installation.kea_build_ddns_intentnow reports a deferral instead of an error when it finds no key material.kea_apply_ddns_intentattaches the D2 connection to the DHCPv4 and DHCPv6 configurations onlywhen a key exists, and returns the deferral for
makedhcpto print as a warning. A management nodethat has run
makedns -ngets the same configuration as before.dhcp_kea_ddns_deferral.tcaptures the missing key reported as an error. It also holds down the twoboundaries the change must keep: a management node whose
site.dnshandleris notddnsasks for noD2 configuration, and an unreadable
networkstable stays an error. The test fails without the fix.