OSAC-1425: PRD: OSAC Tenant UI Networking Section - #82
Conversation
Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Elay Aharoni <elayaha@gmail.com>
|
Warning Review limit reached
Next review available in: 13 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository: osac-project/coderabbit/.coderabbit.yaml Review profile: ASSERTIVE Plan: Enterprise Run ID: 📒 Files selected for processing (1)
WalkthroughA new PRD document is added at ChangesNetworking UI VMaaS Scope PRD
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 11✅ Passed checks (11 passed)
✨ 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 |
There was a problem hiding this comment.
Two issues found after comparing the PRD against the unified-networking EP, the OSAC UI codebase, and the UI/UX specification doc:
1. Attach/detach contradiction
Section 2.2 (Non-Goals) lists:
"Attaching/detaching PublicIPs to compute instances (covered in a separate initiative)"
But FR-27, FR-28, and FR-35 describe exactly this functionality (Attach/Detach row actions, Release blocked if attached, allocate-and-attach in the VM wizard). The UI/UX specification doc (section 4.10) also clearly includes attach/detach flows.
Fix: Remove the "Attaching/detaching PublicIPs to compute instances" line from Non-Goals — the FRs are correct and match the spec.
2. Region is out of scope — remove from all references
Region does not exist on VirtualNetwork in the unified-networking EP or the protobuf types — it lives on NetworkClass, which is a provider-only resource. VirtualNetwork references a NetworkClass via spec.networkClass, and the NetworkClass carries the region. Until the API surfaces region on VirtualNetwork (either as a denormalized field or derived from NetworkClass), Region should not appear in the PRD.
Remove Region from:
- FR-1: list page columns (remove Region column)
- FR-2: filters (remove Region filter) and sorting
- FR-3: create form fields (remove Region dropdown and its validation rule)
- Section 4 acceptance criteria: remove any Region references from acceptance criteria
The UI/UX specification doc has already been updated to remove all Region references from VirtualNetwork pages (list table, detail header, create form, filters, sorting, and validation rules).
|
Good catch! You're absolutely right — FR-27, FR-28, and FR-35 all describe attach/detach functionality for PublicIPs. I've removed that line from Non-Goals. The FRs correctly reflect the spec. Understood on Region. Since Region lives on NetworkClass (provider-only) and isn't surfaced on VirtualNetwork, I've removed all Region references from FR-1, FR-2, FR-3, FR-6, and Section 4. The PRD now aligns with the unified-networking EP and protobuf types. Both issues have been fixed in the latest commit. Thanks for the thorough review! |
|
i don't see change @ElayAharoni, still see region |
- Remove PublicIP attach/detach from Non-Goals (FR-27/28/35 cover this) - Remove all Region references (Region lives on NetworkClass, not VirtualNetwork)
sorry i just posted it |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 10
🤖 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 `@enhancements/networking-ui-vmaas-scope/prd.md`:
- Line 30: Update the VirtualNetwork detail requirements text to use plural
CIDRs or explicitly mention IPv4 and IPv6, because the current singular wording
conflicts with the creation form; adjust the FR-6/VirtualNetwork detail
description to say “IPv4 CIDR (and IPv6 CIDR if configured)” or “CIDRs” so it
matches the fields handled elsewhere in the spec.
- Line 72: FR-42/FR-45 leave the Retry action undefined, so clarify the API
contract for failed-resource retry in the PRD section around the Retry/Delete
actions. Specify whether retry is a UI-only re-submission of the original
request, a dedicated endpoint, or a state-transition call, and name the expected
request/response behavior so implementation can follow the contract.
- Line 46: The SecurityGroup rule spec is inconsistent because FR-20 requires a
Priority column and ordering by priority, but the SecurityGroup create form
definition does not include a Priority field. Update the SecurityGroup
requirements section to either add Priority to the rule fields and form
specification (using the SecurityGroup rule/create form identifiers in this PRD)
or remove the Priority requirement from the table/order behavior if list order
is intended.
- Line 67: Resolve the empty-state wizard flow inconsistency by aligning FR-38
with the inline side-panel overlay pattern already defined in FR-33. Update the
requirements text around the networking virtual network wizard so it no longer
suggests navigating to /networking/virtual-networks as an alternative, and make
FR-38 describe only the inline “Create new VN” flow with return path behavior.
Keep the wording consistent across the related wizard requirements so there is
one clear approach.
- Line 86: Remove the redundant NFR-9 requirement from the PRD and fold any
unique intent into the existing non-functional requirements instead. The issue
is that NFR-9 duplicates the technology and component constraints already
covered by NFR-1 and NFR-4, so update the requirements section to keep a single
source of truth and avoid drift; use the NFR-1, NFR-4, and NFR-9 requirement
entries to locate and consolidate the duplicated text.
- Line 20: The PRD has conflicting language about the AdminNetworksPage topology
view, with Non-Goals saying it is preserved as-is while Open Question 8.2 says
it should be preserved and enhanced. Update the wording in the relevant sections
so they match: either keep the topology view strictly preserved and remove the
“enhanced” premise from the Open Question, or promote topology enhancements into
the Goals section and adjust the Non-Goals statement accordingly. Use the
AdminNetworksPage topology view references and Open Question 8.2 as the anchors
when editing.
- Line 63: Clarify the multi-NIC VirtualNetwork constraint in the PRD: FR-34
currently hard-codes that all subnets in a multi-NIC setup must belong to the
same VN, which may be an unintended platform limitation. Update the requirements
around the multi-NIC flow and the related VM/network attachment behavior to
either explicitly document this as an intentional OSAC restriction with
rationale, or revise the rule to permit different VNs per NIC and describe the
API-level validation in the affected networking wizard/spec sections.
- Line 37: The Subnet detail display pattern is still ambiguous between side
drawer and inline expansion. Update the FR-12 requirement in the PRD to specify
exactly one chosen UI pattern, referencing the Subnet management flow from the
VirtualNetwork detail page; if the decision is not final, move this choice into
Open Questions instead of keeping both options in the requirement.
- Line 54: FR-28 mixes “Release (delete)” with the existing “Allocate”
terminology, which creates inconsistent user-facing wording for PublicIPs.
Standardize the action term across the PublicIP UI and PRD references by
choosing either “Release” or “Delete” and using it consistently in the relevant
feature text, including any column headers, confirmation modals, and toasts tied
to the PublicIP release flow.
- Line 76: The subnet update scope is inconsistent between the requirements
sections: FR-45 omits PATCH for Subnets while Section 6 still includes a subnet
edit endpoint. Update the PRD text to make the Subnets behavior consistent by
either explicitly stating Subnets are create/delete only or adding a subnet
PATCH/edit endpoint everywhere it is referenced, including the relevant
requirement and the /v1/subnets API section.
🪄 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: 12e3a7f4-c914-43d1-a5b1-9803309d2d88
📒 Files selected for processing (1)
enhancements/networking-ui-vmaas-scope/prd.md
- Resolve AdminNetworksPage topology view wording contradiction (issue osac-project#3) - Specify IPv4/IPv6 CIDRs explicitly in FR-6 (issue osac-project#4) - Pick side drawer pattern for subnet detail display in FR-12 (issue osac-project#5) - Add Priority field to SecurityGroup rule specification in FR-18 (issue osac-project#6) - Standardize PublicIP action terminology to 'Release' in FR-28 (issue osac-project#7) - Document multi-NIC same-VN constraint rationale in FR-34 (issue osac-project#8) - Align wizard empty-state flow with inline overlay pattern in FR-38 (issue osac-project#9) - Define Retry action API contract in FR-42 (issue osac-project#10) - Clarify Subnet endpoints are create/delete only in FR-45 (issue osac-project#11) - Remove redundant NFR-9 (issue osac-project#12) - Update Open Question 8.2 wording to match Non-Goals Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Elay Aharoni <elayaha@gmail.com>
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
enhancements/networking-ui-vmaas-scope/prd.md (2)
147-147: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winFix NFR reference in Open Question 8.5.
Line 147 references "NFR-10" but the document only defines NFR-1 through NFR-9. The pagination thresholds described are in NFR-9 (line 86). Update the reference to "NFR-9."
🤖 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 `@enhancements/networking-ui-vmaas-scope/prd.md` at line 147, Update the Open Question 8.5 impact note to reference the correct non-functional requirement: the pagination thresholds belong to NFR-9, not NFR-10. Adjust the wording in the PRD section containing this note so it points to NFR-9 and matches the existing NFR numbering used elsewhere in the document.
134-136: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winResolve or remove stale Open Question 8.1.
FR-33 and FR-38 already specify the inline side-panel overlay pattern (Option A), making this question appear resolved. Either remove 8.1 or convert it to a decision record stating Option (A) was selected, to prevent confusion during implementation.
🤖 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 `@enhancements/networking-ui-vmaas-scope/prd.md` around lines 134 - 136, The Open Question 8.1 is stale because FR-33 and FR-38 already establish the inline side-panel overlay approach. Update the PRD section around the 8.1 question to either remove it entirely or rewrite it as a decision record that explicitly states Option (A) was selected. Use the existing FR-33, FR-38, and “What specific enhancements to the AdminNetworksPage topology view are in scope?” section as anchors to keep the scope consistent and avoid implementation confusion.
🤖 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 `@enhancements/networking-ui-vmaas-scope/prd.md`:
- Line 32: Several Markdown headings in the PRD are missing required blank lines
around them, which can trigger MD022 and inconsistent rendering. Update the
heading blocks for Subnets, Security Groups, Public IPs, Sidebar Navigation,
VMaaS Wizard Integration, and Error States and Edge Cases so each heading in the
document has a blank line both before and after it. Use the existing heading
lines as anchors and keep the surrounding content unchanged.
- Around line 45-46: Clarify the SecurityGroup rule edit contract by updating
the PRD to specify how the row-level Edit/Delete actions in FR-20 are
implemented against the API surfaced by FR-45. Decide whether `PATCH
/v1/securitygroups/{id}` replaces the full ruleset or whether separate
rule-level endpoints are available, and reflect that choice explicitly near the
SecurityGroups and rule-management requirements so implementers can wire the UI
actions to the correct contract.
- Around line 60-64: FR-32 and FR-34 conflict on whether each network attachment
can pick its own Virtual Network. Update the PRD to make the UX consistent with
the same-VN constraint by clarifying in the Network Attachment and multi-NIC
requirements whether Virtual Network is selected once globally for the wizard
or, if kept per attachment, subsequent VN selectors are locked/disabled after
the first choice. Reference the Network Attachment section, FR-32, and FR-34 so
the implementation can follow a single source of truth.
---
Outside diff comments:
In `@enhancements/networking-ui-vmaas-scope/prd.md`:
- Line 147: Update the Open Question 8.5 impact note to reference the correct
non-functional requirement: the pagination thresholds belong to NFR-9, not
NFR-10. Adjust the wording in the PRD section containing this note so it points
to NFR-9 and matches the existing NFR numbering used elsewhere in the document.
- Around line 134-136: The Open Question 8.1 is stale because FR-33 and FR-38
already establish the inline side-panel overlay approach. Update the PRD section
around the 8.1 question to either remove it entirely or rewrite it as a decision
record that explicitly states Option (A) was selected. Use the existing FR-33,
FR-38, and “What specific enhancements to the AdminNetworksPage topology view
are in scope?” section as anchors to keep the scope consistent and avoid
implementation confusion.
🪄 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: 18abf529-bf92-4331-8eb4-e216956033a0
📒 Files selected for processing (1)
enhancements/networking-ui-vmaas-scope/prd.md
osac-jira-ai-issue-solver
Bot
added
rfe-creator-auto-reviewed
There was a problem hiding this comment.
Good progress — the Region removal and attach/detach Non-Goals fix both look correct. A few issues remain after verifying the PRD against the protobuf definitions and the OSAC UI codebase:
Critical
1. Wrong REST endpoint paths (FR-45)
All paths are incorrect. The actual gateway paths have the /api/fulfillment prefix and use snake_case:
| FR-45 says | Actual |
|---|---|
/v1/virtualnetworks |
/api/fulfillment/v1/virtual_networks |
/v1/securitygroups |
/api/fulfillment/v1/security_groups |
/v1/publicips |
/api/fulfillment/v1/public_ips |
/v1/publicippools |
/api/fulfillment/v1/public_ip_pools |
/v1/subnets |
/api/fulfillment/v1/subnets |
Also: FR-45 should list the PublicIPAttachments endpoints (/api/fulfillment/v1/public_ip_attachments) so implementers know attach/detach uses a separate resource (Create PublicIPAttachment = attach, Delete PublicIPAttachment = detach), not direct actions on PublicIP.
Major
2. SecurityRule has no priority or description fields
FR-18 lists "Priority (integer, determines rule evaluation order)" and "Description (optional)" on each rule. The actual SecurityRule proto only has five fields: protocol, port_from, port_to, ipv4_cidr, ipv6_cidr. No priority, no description. Either add these as API dependencies in Section 6, or remove them from FR-18 and FR-20.
3. Subnet "Available IPs" has no API backing (FR-9)
FR-9 specifies an "Available IPs (used/total)" column. SubnetStatus only has state and message — no used/available IP count. Total can be derived from the CIDR client-side, but "used" cannot. Drop "used/total" or add it as an API dependency.
4. Consider adding NetworkClass to VN create form (FR-3)
VirtualNetworkSpec.network_class is optional (defaults to the platform default if one exists), but the create form should still expose it as a dropdown so users can choose their network infrastructure — especially in deployments with multiple NetworkClasses. Creation will also fail if no default is configured and the field is omitted.
Minor
5. Risk 7.1 is already mitigated
OSAC UI is confirmed on PatternFly 6.4.x. This risk can be marked resolved.
Critical fixes from danmanor: - Add NetworkClass dropdown to VN create form (FR-3) - required field - Fix all REST endpoint paths to use /api/fulfillment prefix and snake_case (FR-45) - Clarify PublicIP attach/detach requires private API endpoints (Assumption 5, Section 6) Major fixes from danmanor: - Remove Priority and Description from SecurityRule fields (FR-18, FR-20) - not in proto - Remove 'Available IPs (used/total)' column from Subnets table (FR-9) - no API backing - Mark PatternFly version mismatch risk as RESOLVED (Risk 7.1) CodeRabbit feedback: - Add blank lines around all section headings (MD022 linter) Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Elay Aharoni <elayaha@gmail.com>
|
All 6 issues addressed in commit 4b7477d: Critical:
Major: Minor: Thanks for the detailed review and catching the API contract mismatches! |
danmanor
left a comment
danmanor
left a comment
There was a problem hiding this comment.
Looks good — all prior feedback addressed. Three small issues introduced in the latest round:
-
Assumption 5 & Section 6: PublicIPAttachments IS in the public API. The note saying attach/detach "requires the private API endpoint
/api/private/v1/public_ip_attachments" is incorrect —PublicIPAttachmentsis exposed in the public API at/api/fulfillment/v1/public_ip_attachmentswith full CRUD. Remove the private API references and update Section 6 to point to the public endpoint. -
FR-20 still has the old path format. Says
PATCH /v1/securitygroups/{id}— should be/api/fulfillment/v1/security_groups/{id}. -
FR-32 still mentions "available IP count" for subnets. FR-9 was correctly fixed, but FR-32 in the wizard section still says "showing CIDR and available IP count" —
SubnetStatusdoesn't have that data. Drop "and available IP count" to match FR-9.
None of these block approval — approving now, just fix before merge.
… add description NetworkClass proto has no region field. The dropdown should show name and description instead. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Elay Aharoni <elayaha@gmail.com>
1. Fix FR-20: correct SecurityGroup PATCH endpoint path format
- Changed from /v1/securitygroups/{id} to /api/fulfillment/v1/security_groups/{id}
2. Fix FR-32: remove 'available IP count' from subnet dropdown
- SubnetStatus doesn't include IP count data
3. Fix Assumption 5 & Section 6: PublicIPAttachments is in public API
- Remove references to private API endpoint
- Update to use /api/fulfillment/v1/public_ip_attachments (public API)
- Add PublicIPAttachment to required types list
Assisted-by: Claude Code <noreply@anthropic.com>
Signed-off-by: Elay Aharoni <elayaha@gmail.com>
ElayAharoni
changed the title
|
@ElayAharoni: This pull request references OSAC-1425 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 task 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 APPROVED This pull-request has been approved by: danmanor, ElayAharoni The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
| #### Virtual Networks | ||
| - **FR-1:** The UI must provide a VirtualNetworks list page (`/networking/virtual-networks`) displaying all VirtualNetworks owned by the tenant with columns for Name, IPv4 CIDR, Subnets count, and Status | ||
| - **FR-2:** The VirtualNetworks list page must support filtering by Status, sorting by Name/Status, and searching by Name | ||
| - **FR-3:** The UI must provide a "Create virtual network" action that opens a side panel form with fields for NetworkClass (required dropdown showing available NetworkClasses with name and description), Name (required, DNS-valid, unique within tenant), IPv4 CIDR (required, /16 to /24 range), and IPv6 CIDR (optional) |
There was a problem hiding this comment.
I don't this the tenant user should choose the network class. For now it should be hardcoded to CUDN and later on it should be handled by the infrastructure admin via the enclave. @danmanor wdyt?
There was a problem hiding this comment.
Should we still show NetworkClass in the VN list/detail pages (read-only), or completely hide it from tenant users?
There was a problem hiding this comment.
hide it. There tenant user shouldn't be aware to the network class.
|
|
||
| - **FR-23:** The UI must provide a PublicIPs list page (`/networking/public-ips`) displaying all PublicIPs allocated to the tenant with columns for Address, Pool, Attached To (resource name + type, or dash if unattached), and Status | ||
| - **FR-24:** The PublicIPs list page must support filtering by Pool, Status, and Attached (yes/no) | ||
| - **FR-25:** The UI must provide an "Allocate IP" action that opens a modal dialog with fields for Pool (required dropdown showing available pools with remaining IP count, e.g., "external-pool-1 (Available: 245 IPs)") and Name (required, label for this allocation) |
There was a problem hiding this comment.
The ComputeInstance form should have only a checkbox with "Allocate Public IP" and "IP Family" - IPv4 or IPv6, then the IP will be automatically allocated. Here is the task explaining the change - https://redhat.atlassian.net/browse/OSAC-1712. Hopefully it will be merged today.
There was a problem hiding this comment.
With automatic allocation, can users still choose which pool to allocate from or is the pool selection completely automatic based on IP family?
There was a problem hiding this comment.
completely automatic based on IP family. And if IP famialy is not chosen it fallbacks to IPv4.
There was a problem hiding this comment.
@AlonaKaplan , we discussed this approach within our team and with @danmanor, we got to a conclusion that this is not the best approach.
because from a UI perspective it is not the best practice to sent 2 API POST calls that depend on each other when creating from a wizard (it can cause issues with error handling, and failures).
the best approach right now is to create the vm from the wizard and attach the public ip later from the vm details page.
let me know what do you think.
There was a problem hiding this comment.
I still think the Public IP checkbox should be available during creation, as it provides a better user experience. In the 0.2 release, we can consolidate the backend flow into a single creation action.
| - **FR-31:** The VM creation wizard (`/vms/create/:catalogItemId`) must include a Network Configuration step after basic VM settings (name, SSH key, etc.) with sections for Network Attachment and Public IP (optional) | ||
| - **FR-32:** The Network Attachment section must provide fields for Virtual Network (required dropdown showing all tenant VNs with name and CIDR, with "Create new VN" link), Subnet (required dropdown filtered to selected VN, showing CIDR, with "Create new Subnet" link), and Security Groups (optional multi-select checkboxes showing SGs scoped to selected VN with rule count summary, with "Create new Security Group" link) | ||
| - **FR-33:** When a user clicks "Create new VN" from the wizard, the UI must open the Create VN side panel that overlays the wizard—after VN creation, the new VN must be auto-selected in the wizard | ||
| - **FR-34:** The wizard must support multi-NIC configuration via an "[+ Add another network attachment]" button—each attachment has its own VN/Subnet/SG selection, and exactly one attachment must be marked as Primary (radio button) which determines the default gateway. Note: All subnets must belong to the same VirtualNetwork (OSAC platform constraint to simplify initial networking model; future phases may support cross-VN attachments) |
There was a problem hiding this comment.
Currently we support only on attachment and one subnet. cc @danmanor
|
|
||
| #### Sidebar Navigation | ||
|
|
||
| - **FR-29:** The tenant user sidebar must add a new "Networking" section with sub-items: Virtual Networks, Security Groups, Public IPs (Subnets are not a sidebar item) |
There was a problem hiding this comment.
why subnets are not a sidebar item?
There was a problem hiding this comment.
because subnets are tightly coupled to their VirtualNetwork, They are essentially VirtualNetwork configuration, not standalone resources as i understand.
| - **FR-9:** The Subnets tab on the VirtualNetwork detail page must display all subnets belonging to that VN in a table with columns for Name, CIDR, and Status | ||
| - **FR-10:** The Subnets tab must provide a "Create subnet" action that opens a side panel form with the parent VN pre-selected and fields for Name (required, DNS-valid) and CIDR (required, must be within parent VN CIDR, must not overlap existing subnets) | ||
| - **FR-11:** The Create Subnet form must show the parent VN CIDR as context and display existing subnet CIDRs to help users select a non-overlapping range | ||
| - **FR-12:** Clicking on a subnet name must show subnet metadata and a list of attached resources (compute instances) in a side drawer |
There was a problem hiding this comment.
Why does just the subnet has this option and the virtualnet/securitygroup don't?
There was a problem hiding this comment.
because subnets have minimal metadata, and using a full page with tabs like in VN's or security groups seems too heavy for that.. but i can align all of them to use full page if we prefer the consistency.
There was a problem hiding this comment.
ok i will implement it as it is now and we can change it in the future if we think it will be better to align all
4 participants
PRD: OSAC Tenant UI Networking Section
Jira: OSAC-1425
Summary
This PRD specifies a dedicated Networking section for the OSAC tenant UI that enables tenant users to create and manage VirtualNetworks, Subnets, SecurityGroups, and PublicIPs through a web interface. It also covers integration with the VMaaS wizard to allow inline creation of networking resources during VM provisioning, reducing friction for new tenants and improving the overall user experience.
Requesting Review On
How to Review
Summary by CodeRabbit