bug: dpf: Fix for Bf4 mandatory services overwriting bf3 services.#3404
bug: dpf: Fix for Bf4 mandatory services overwriting bf3 services.#3404abvarshney-nv wants to merge 1 commit into
Conversation
Summary by CodeRabbit
WalkthroughChangesPer-deployment CR naming
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant DeploymentInitialization
participant ResourceBuilders
participant DPUDeployment
participant KubernetesResources
DeploymentInitialization->>ResourceBuilders: compute and pass deployment suffix
ResourceBuilders->>KubernetesResources: create suffixed service and NAD CRs
ResourceBuilders->>DPUDeployment: provide suffixed service references
DPUDeployment->>KubernetesResources: retain logical service-map keys
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
crates/dpf/src/sdk.rs (1)
608-641: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick winDisambiguate live version lookup
get_dpf_service_versionsmatches live templates withdeployment_service_nameonly. BF3 and BF4 now share that logical name, while onlymetadata.nameis suffixed, so the firstfind(...)hit can report the wronglive_helm_version/live_docker_image_tagdepending on list order. Match bycr_nameor add a deployment discriminator.🤖 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/dpf/src/sdk.rs` around lines 608 - 641, The live-template lookup in get_dpf_service_versions must disambiguate services that share deployment_service_name. Match each template using its suffixed metadata.name/cr_name derived from the service name and suffix, or apply an equivalent deployment discriminator, so live_helm_version and live_docker_image_tag come from the correct template regardless of list order.
🧹 Nitpick comments (1)
crates/dpf/src/sdk.rs (1)
781-791: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚖️ Poor tradeoffPrefer a parameters struct over
#[allow(clippy::too_many_arguments)].Adding
suffixtipsbuild_deploymentpast Clippy's argument threshold, and the fix here is to silence the lint. The house style is to avoid broad#[allow(...)]; a positional argument list of this size is also error-prone at the call sites (e.g. it is easy to transposeflavor_name/namespace). Consider grouping the inputs into aDeploymentParamsstruct (constructed with named fields), which removes the lint, restores compile-time clarity, and reads better than eight positional arguments.As per coding guidelines: "Avoid using
#[allow(...)]unless you have a strong reason to do so" and "If you have a large struct with lots of required fields ... consider splitting it into two types."🤖 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/dpf/src/sdk.rs` around lines 781 - 791, Replace the positional arguments of build_deployment with a DeploymentParams struct containing the required deployment inputs, including suffix, and remove the #[allow(clippy::too_many_arguments)] attribute. Update all callers to construct DeploymentParams using named fields, preserving the existing deployment behavior and value mappings.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.
Outside diff comments:
In `@crates/dpf/src/sdk.rs`:
- Around line 608-641: The live-template lookup in get_dpf_service_versions must
disambiguate services that share deployment_service_name. Match each template
using its suffixed metadata.name/cr_name derived from the service name and
suffix, or apply an equivalent deployment discriminator, so live_helm_version
and live_docker_image_tag come from the correct template regardless of list
order.
---
Nitpick comments:
In `@crates/dpf/src/sdk.rs`:
- Around line 781-791: Replace the positional arguments of build_deployment with
a DeploymentParams struct containing the required deployment inputs, including
suffix, and remove the #[allow(clippy::too_many_arguments)] attribute. Update
all callers to construct DeploymentParams using named fields, preserving the
existing deployment behavior and value mappings.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 5c30d5f8-af4f-4b3d-992b-11ef84ded62a
📒 Files selected for processing (1)
crates/dpf/src/sdk.rs
🔍 Container Scan Summary
Per-CVE detail lives in the per-service |
Suffix DPUServiceTemplate/Configuration/NAD CR names (and the deployment's references to them) per deployment so BF3 and BF4 no longer clobber each other's Helm values/version in the shared namespace. BF3 keeps its original unsuffixed names (no rename/orphaning); only BF4 is suffixed.
Related issues
Type of Change
Breaking Changes
Testing
Additional Notes