feat(dhcp): hold IPv6 DNS resolvers in DhcpConfig alongside IPv4#2685
feat(dhcp): hold IPv6 DNS resolvers in DhcpConfig alongside IPv4#2685chet wants to merge 1 commit into
Conversation
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (6)
🚧 Files skipped from review as they are similar to previous changes (5)
Summary by CodeRabbitRelease Notes
WalkthroughThe PR adds ChangesIPv6 Nameserver Support in DhcpConfig
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related issues
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
⚔️ Resolve merge conflicts
Comment |
|
@coderabbitai PTAL, thank you! |
|
✅ Action performedReview finished.
|
There was a problem hiding this comment.
🧹 Nitpick comments (1)
crates/dhcp-server/src/grpc_server.rs (1)
244-265: ⚡ Quick winUse a table-driven scenario for IPv6 parse success/failure cases.
These two tests exercise the same fallible conversion with different inputs; consolidating them into a single
scenarios!table would better match repo test conventions and make new cases easier to add.As per coding guidelines, “Reach for a table whenever two or more tests call the same operation with different inputs” and “Use
carbide_test_support::scenarios!macro withOutcome(Yields/Fails/FailsWith) for fallible operations returningResultin Rust tests.”🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@crates/dhcp-server/src/grpc_server.rs` around lines 244 - 265, Consolidate the two test functions `parses_ipv6_nameservers_from_proto` and `rejects_malformed_ipv6_nameserver` into a single table-driven test using the `scenarios!` macro from `carbide_test_support`. Define multiple test scenarios for the ModelDhcpConfig::try_from() conversion: one scenario using `Yields` with valid IPv6 addresses in the carbide_nameservers_v6 field that successfully parses, and another scenario using `Fails` with malformed IP addresses that should result in an error. This approach follows the repository's test conventions for consolidating multiple tests that exercise the same fallible operation with different inputs.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@crates/dhcp-server/src/grpc_server.rs`:
- Around line 244-265: Consolidate the two test functions
`parses_ipv6_nameservers_from_proto` and `rejects_malformed_ipv6_nameserver`
into a single table-driven test using the `scenarios!` macro from
`carbide_test_support`. Define multiple test scenarios for the
ModelDhcpConfig::try_from() conversion: one scenario using `Yields` with valid
IPv6 addresses in the carbide_nameservers_v6 field that successfully parses, and
another scenario using `Fails` with malformed IP addresses that should result in
an error. This approach follows the repository's test conventions for
consolidating multiple tests that exercise the same fallible operation with
different inputs.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: af422fe8-0573-4f77-b2ae-c7147a5f8431
📒 Files selected for processing (5)
crates/agent/src/dhcp_server_grpc_client.rscrates/agent/src/ethernet_virtualization.rscrates/dhcp-server/proto/dhcp_server_control.protocrates/dhcp-server/src/grpc_server.rscrates/rpc-utils/src/dhcp.rs
The DPU agent already learns both IPv4 and IPv6 DNS resolvers for a host (the dual-stack `ServiceAddresses.nameservers`), but the `DhcpConfig` it hands to `forge-dhcp-server` only holds the IPv4 ones. This gives the config a parallel `carbide_nameservers_v6`, in both the `dhcp_server_control` proto and the `DhcpConfig` model, so a host's IPv6 resolvers have somewhere to live across the agent -> dhcp-server channel. This is the data-model foundation for advertising dual-stack DNS resolvers to IPv6 instances. The pieces that fill it in -- populating the field from the agent, and choosing how the address reaches a host (RA RDNSS or DHCPv6) -- are follow-on work. - The IPv4 `carbide_nameservers` field is unchanged, so the DHCPv4 option-6 path behaves exactly as before. - `carbide_nameservers_v6` is omitted from the serialized config when empty, so the on-disk format is identical for IPv4-only deployments and configs written by older agents still deserialize. Tests cover the new field round-tripping through serde and through both proto conversions, including a malformed-address rejection. This supports NVIDIA#2638. Signed-off-by: Chet Nichols III <chetn@nvidia.com>
|
@coderabbitai Thanks for the eyes. Updated -- consolidated the two |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: #!/bin/bash
gh pr view 2685 --repo NVIDIA/infra-controller --json state,title,isDraft
echo "---"
gh pr diff 2685 --repo NVIDIA/infra-controllerLength of output: 10013
Resolving all open comments now. [resolve] |
|
Closing — superseded by #2672 ( The one remaining unique piece — the agent populating |
Summary
Adds a parallel IPv6 nameserver field to the
DhcpConfigthe agent hands toforge-dhcp-server, so a host's IPv6 DNS resolvers have somewhere to live alongside the existing IPv4carbide_nameservers.dhcp_server_control.protoand theDhcpConfigmodel gaincarbide_nameservers_v6(field 9), with#[serde(default, skip_serializing_if = "Vec::is_empty")]so IPv4-only configs serialize byte-identically and configs written by older agents still deserialize.From<ModelDhcpConfig>/TryFrom<proto::DhcpConfig>) handle the new field; the IPv4 path is untouched.This is plumbing ahead of a consumer — nothing reads the IPv6 field until the delivery channel lands (see #2644 / #1263).
Implements #2638. Part of the #2628 epic (dual-stack DNS resolver advertisement for IPv6).
Draft pending review.