OSAC-1533: Fix --network-attachment ignored with --catalog-item#705
OSAC-1533: Fix --network-attachment ignored with --catalog-item#705obochan-rh wants to merge 2 commits into
Conversation
The buildSpecFromCatalogItem() function was missing the applyNetworkingFlags() call, causing --network-attachment flags to be silently dropped when creating compute instances via --catalog-item. The sibling buildSpec() function (used by --template) already includes this call. Signed-off-by: Ofer Bochan <obochan@redhat.com>
Verify that --network-attachment flags are correctly applied when using --catalog-item, matching the existing buildSpec test coverage. Signed-off-by: Ofer Bochan <obochan@redhat.com>
|
@obochan-rh: This pull request references OSAC-1533 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the bug to target the "5.0.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: obochan-rh The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Walkthrough
ChangesNetwork Attachment Flags in Catalog-Item Spec Builder
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Poem
🚥 Pre-merge checks | ✅ 11✅ Passed checks (11 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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.
Inline comments:
In `@internal/cmd/cli/create/computeinstance/create_compute_instance_cmd_test.go`:
- Around line 76-103: Add a new test case (It block) to the
buildSpecFromCatalogItem describe suite that validates error handling for
invalid input. Create a runnerContext with invalid or malformed values in the
networkAttachments field (such as a string that cannot be parsed correctly),
then call buildSpecFromCatalogItem and assert that it returns an error using
Expect(err).To(HaveOccurred()). This ensures the function properly rejects and
reports invalid network attachment input rather than silently ignoring it.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: osac-project/coderabbit/.coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: 0c1643c5-4e52-4a45-8607-79571a46f6bf
📒 Files selected for processing (2)
internal/cmd/cli/create/computeinstance/create_compute_instance_cmd.gointernal/cmd/cli/create/computeinstance/create_compute_instance_cmd_test.go
| var _ = Describe("buildSpecFromCatalogItem", func() { | ||
| It("should populate attachments when network-attachment flags are set", func() { | ||
| c := &runnerContext{} | ||
| c.args.networkAttachments = []string{"n1", "subnet=n2,security-groups=g1"} | ||
| spec, err := c.buildSpecFromCatalogItem("cat-001") | ||
| Expect(err).NotTo(HaveOccurred()) | ||
|
|
||
| want := publicv1.ComputeInstanceSpec_builder{ | ||
| CatalogItem: "cat-001", | ||
| NetworkAttachments: []*publicv1.NetworkAttachment{ | ||
| publicv1.NetworkAttachment_builder{Subnet: "n1"}.Build(), | ||
| publicv1.NetworkAttachment_builder{Subnet: "n2", SecurityGroups: []string{"g1"}}.Build(), | ||
| }, | ||
| }.Build() | ||
| Expect(proto.Equal(spec, want)).To(BeTrue(), "spec should equal expected spec") | ||
| }) | ||
|
|
||
| It("should return spec without attachments when no network flags are set", func() { | ||
| c := &runnerContext{} | ||
| spec, err := c.buildSpecFromCatalogItem("cat-002") | ||
| Expect(err).NotTo(HaveOccurred()) | ||
|
|
||
| want := publicv1.ComputeInstanceSpec_builder{ | ||
| CatalogItem: "cat-002", | ||
| }.Build() | ||
| Expect(proto.Equal(spec, want)).To(BeTrue(), "spec should equal expected spec") | ||
| }) | ||
| }) |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial | ⚡ Quick win
Add a catalog-item error-path test for invalid network attachment input.
This suite validates success/empty cases but not parse failure propagation; add one case where networkAttachments contains an invalid value and assert buildSpecFromCatalogItem returns an error, so future regressions don’t silently drop invalid networking input.
🤖 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 `@internal/cmd/cli/create/computeinstance/create_compute_instance_cmd_test.go`
around lines 76 - 103, Add a new test case (It block) to the
buildSpecFromCatalogItem describe suite that validates error handling for
invalid input. Create a runnerContext with invalid or malformed values in the
networkAttachments field (such as a string that cannot be parsed correctly),
then call buildSpecFromCatalogItem and assert that it returns an error using
Expect(err).To(HaveOccurred()). This ensures the function properly rejects and
reports invalid network attachment input rather than silently ignoring it.
2 participants
Summary
buildSpecFromCatalogItem()was missing theapplyNetworkingFlags()call, causing--network-attachmentflags to be silently dropped when creating compute instances via--catalog-itembuildSpec()function (used by--template) already included this callbuildSpecFromCatalogItemto verify network attachments are correctly appliedRoot Cause
When
--catalog-itemsupport was added,buildSpecFromCatalogItem()duplicated all optional flag handling frombuildSpec()(image, cores, memory, ssh-key, disks, etc.) but omitted theapplyNetworkingFlags()call at the end. The CLI accepted--network-attachmentwithout error but never included it in the gRPC request.Fix
Added
applyNetworkingFlags(&spec)inbuildSpecFromCatalogItem()before returning — same pattern asbuildSpec()(3 lines).Test Plan
buildSpecFromCatalogItemtests verify network attachments are populated"at least one network attachment is required"(network attachment dropped) to"subnet does not exist"(network attachment correctly sent to server)Fixes: https://redhat.atlassian.net/browse/OSAC-1533
Summary by CodeRabbit
New Features
Tests