[docker-dhcp-relay] Start dhcp6relay unconditionally; apply IPv6 relay config at runtime#28042
[docker-dhcp-relay] Start dhcp6relay unconditionally; apply IPv6 relay config at runtime#28042AnantKishorSharma wants to merge 2 commits into
Conversation
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azpw retry |
|
Retrying failed(or canceled) jobs... |
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
84e89a6 to
6c6bf05
Compare
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azpw retry |
|
Retrying failed(or canceled) jobs... |
|
Retrying failed(or canceled) stages in build 1152852: ✅Stage Test:
|
|
@Xichen96 Can you help review this change? |
|
@anders-nexthop Please help review as well |
|
The failing
Once the fix merges, this check should go green on re-run. |
|
/azpw retry |
|
Retrying failed(or canceled) jobs... |
|
Build not found. Please close and reopen the PR or rebase your branch to trigger a new build. |
|
/azpw run |
|
Retrying failed(or canceled) jobs... |
|
Build not found. Please close and reopen the PR or rebase your branch to trigger a new build. |
…y config at runtime Start dhcp6relay unconditionally instead of gating it on dhcpv6_servers, skip the dhcp_relay container restart on the IPv6 config path, and bound the per-interface readiness wait when has_sonic_dhcpv4_relay is set. Regenerate the affected goldens and make the cli-plugin tests version-aware. Signed-off-by: Anant Kishor Sharma <anant.kishor-sharma@hpe.com>
6c6bf05 to
7db26c0
Compare
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@Xichen96 @anders-nexthop - could you please help review? Thanks! |
|
/azpw run |
|
Retrying failed(or canceled) jobs... |
|
Retrying failed(or canceled) stages in build 1163924: ✅Stage Test:
|
anders-nexthop
left a comment
anders-nexthop
left a comment
There was a problem hiding this comment.
Thanks for this — the design reads well: dhcp6relay started unconditionally so runtime DHCP_RELAY changes apply without a container restart, the dual-ToR -u Loopback0 gating preserved (good to see the new test_j2files assertion for it), and the CLI dropping the v6-path restart. One sequencing note and one question.
NOTE: this depends on sonic-net/sonic-dhcp-relay#116, so it should land only once the src/dhcprelay pin has advanced to include it. Against an earlier dhcp6relay the changes here would regress — #116's summary notes the agent previously "read the DHCP_RELAY table once at startup and required a dhcp_relay container restart for any subsequent relay configuration change," so without it, skipping the v6-path restart (config/plugins/dhcp_relay.py) would leave an IPv6 config dhcp_relay add with no effect, and the unconditional start would run the agent before #116's runtime-reconcile and warning-throttle. Purely a merge-order thing; the question below is independent of it.
— anders-bot (AI-assisted, on behalf of @anders-nexthop)
…s_sonic_dhcpv4_relay via WAIT_IFACE_READY_TIMEOUT_V6 (+test) Signed-off-by: Anant Kishor Sharma <anant.kishor-sharma@hpe.com>
|
/azp run Azure.sonic-buildimage |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
|
/azpw retry |
|
Retrying failed(or canceled) jobs... |
|
Retrying failed(or canceled) stages in build 1168563: ✅Stage Test:
|
4 participants
Fixes #28048
Why I did it
With the SONiC-native
dhcp6relayapplyingDHCP_RELAYchanges at runtime (sonic-net/sonic-dhcp-relay#116), the agent no longer needs to be gated on the presence ofdhcpv6_serversat render time, and thedhcp_relaycontainer no longer needs to be restarted for an IPv6 relay configuration change.How I did it
dhcpv6-relay.agents.j2/dhcp-relay.programs.j2: startdhcp6relayunconditionally. The dual ToR-u Loopback0option is unchanged from upstream — it is still passed only whenDEVICE_METADATAsubtypeisDualToR.cli/config/plugins/dhcp_relay.py: skip thedhcp_relaycontainer restart on the IPv6 path, sincedhcp6relayreconcilesDHCP_RELAYat runtime.wait_for_intf.sh.j2: bound the per-interface readiness waits so a never-ready interface cannot block startup. The IPv4 waits (WAIT_IFACE_READY_TIMEOUT) are bounded (300s) only whenhas_sonic_dhcpv4_relayis set; legacy ISC dhcrelay keeps the wait-forever default. The IPv6 VLAN waits (WAIT_IFACE_READY_TIMEOUT_V6) are always bounded (300s) sincedhcp6relayreconciles at runtime, independent of the v4 relay type.wait_for_intf_v4_relay.shgolden for thehas_sonic_dhcpv4_relay=Truebranch) and made the cli-plugin tests version-aware. Addedtest_j2filescases asserting thehas_sonic_dhcpv4_relay=Truewait rendering and that-u Loopback0renders only forsubtype == DualToR.How to verify it
src/sonic-config-engine:test_j2files.py::TestJ2Files::test_dhcp_relaypasses (goldens + thehas_sonic_dhcpv4_relay=Trueand Dual-ToR render assertions).Companion PRs: sonic-net/sonic-dhcp-relay#116 (core) · sonic-net/sonic-mgmt sonic-net/sonic-mgmt#25589 (tests) · sonic-net/SONiC sonic-net/SONiC#2402 (HLD)