PRD for base OS management for bare-metal instances - #162
ItzikEzra-rh wants to merge 1 commit into
Conversation
Adds PRD for integrating the DiskImage resource (OSAC-2540) into BMaaS, enabling tenants to select OS images when provisioning bare metal instances. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Itzik Ezra <iezra@redhat.com>
|
@ItzikEzra-rh: This pull request references OSAC-1270 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 feature 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: ItzikEzra-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 |
WalkthroughAdds the OSAC-1270 PRD for Base OS Management for Bare-Metal Instances, covering DiskImage selection, catalog defaults, deletion protection, visibility rules, dependencies, user stories, and acceptance criteria. ChangesBase OS Management
Estimated code review effort: 1 (Trivial) | ~3 minutes Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 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 |
AI EP Review: EP-162Score: 10/10 | Verdict: PASS
Verdict: A well-structured, focused PRD that clearly describes user-facing DiskImage integration into BMaaS with concrete justification, proper persona coverage, no design leakage, and fully testable acceptance criteria. Feedback: Strong PRD overall. Two improvements: (1) Add a Tenant User story for the default-image happy path — currently the defaulting behavior is only described from the Admin's catalog-creation perspective, but the Tenant User who benefits from it has no story capturing that experience. (2) Address the documentation and UI cross-cutting dimensions explicitly, even if just to state 'documentation deferred to OSAC-2540' and 'UI image selector in scope, lifecycle UI deferred' — the In Scope bullet mentions 'UI/API support' but doesn't specify which persona workflows need console support or whether documentation is in scope for this milestone. Critical (0)None. Important (2)
Suggestions (3)
Review costModel: claude-opus-4-6 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 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/OSAC-1270-base-os-management/prd.md`:
- Around line 23-27: Update the PRD terminology throughout to use the canonical
resource names BareMetalInstance and BareMetalInstanceCatalogItem, replacing
every occurrence of BaremetalInstance and BaremetalInstanceCatalogItem while
preserving the documented behavior and references.
- Line 68: Update the DiskImage deletion acceptance criterion to specify that
deletion is rejected only when referenced by BaremetalInstances or
BaremetalInstanceCatalogItems that are not deleted, allowing references from
deleted historical resources.
- Line 23: Update the BaremetalInstance creation requirement to explicitly
define precedence when both user-selected and catalog-default DiskImage
references are present; specify whether the explicit DiskImage overrides the
catalog default or conflicting values are rejected, and ensure the provisioning
behavior follows that rule.
- Around line 25-27: Update the DiskImage selection and provisioning acceptance
criteria to enforce OSAC-2540 eligibility: allow only globally visible or
same-tenant images, block obsolete images from new bare-metal provisioning, and
preserve OSAC-2540 behavior for deprecated images. Apply the same eligibility
requirements to the related criteria at the additional referenced section.
- Around line 2-5: Update the OSAC-1270 PRD metadata to set the Jira target
version to 5.0.0, preserving the existing prd_id, title, jira_key, and status
fields.
🪄 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: Pro Plus
Run ID: c50cc97a-e408-47c2-ab47-11de304e17fe
📒 Files selected for processing (1)
enhancements/OSAC-1270-base-os-management/prd.md
| prd_id: OSAC-1270 | ||
| title: Base OS Management for Bare-Metal Instances | ||
| jira_key: OSAC-1270 | ||
| status: Draft |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== repo files around prd =="
git ls-files | grep -E '(^|/)prd\.md$|OSAC-1270|base-os-management' || true
echo "== target file excerpt =="
if [ -f enhancements/OSAC-1270-base-os-management/prd.md ]; then
cat -n enhancements/OSAC-1270-base-os-management/prd.md | sed -n '1,80p'
else
echo "target file not found"
fi
echo "== Jira target version references for OSAC-1270 across repo =="
rg -n "OSAC-1270|target.?version|target_version|5\.0\.0|version" -S . || trueRepository: osac-project/enhancement-proposals
Length of output: 50390
🌐 Web query:
osac OSAC-1270 Jira target version 5.0.0 base os management bare metal
💡 Result:
A comprehensive search of available technical documentation and public repositories yielded no evidence of an issue or feature identified as OSAC-1270 relating to version 5.0.0, base OS management, or bare-metal configurations [1][2][3][4][5]. The search results for the term OSAC in the context of Jira (often seen in project management systems) returned various unrelated entries, such as Apache projects (LENS-1270, REEF-1270, MRM-1270) [2][4][5] and general hardware identifiers (e.g., Huawei S12700 series switches, Intel Xeon E3-1270, Advantech ECU-1270) [6][7][8][9][10][11][12]. The term "osac-operator" exists as a GitHub project [3], but no specific association with an issue numbered "1270" and the specified version or configuration was found [3]. If OSAC-1270 refers to a proprietary or internal ticketing system, please verify the ticket number, project name, or the specific organization to which the issue belongs, as this information is not available in public technical databases.
Citations:
- 1: https://jira.atlassian.com/browse/AX-1270
- 2: https://issues.apache.org/jira/browse/LENS-1270
- 3: https://dependabot.ecosyste.ms/hosts/GitHub/repositories/osac-project%2Fosac-operator
- 4: https://issues-test.apache.org/jira/browse/REEF-1270
- 5: https://issues-test.apache.org/jira/browse/MRM-1270
- 6: https://support.huawei.com/enterprise/en/doc/EDOC1100515534/dd66629b/understanding-a-basic-software-package
- 7: https://support.huawei.com/enterprise/en/doc/EDOC1100333876/d9b3926/version-requirements
- 8: https://support.huawei.com/enterprise/en/doc/EDOC1100333439/7252523e/cloud-based-management-configuration-of-ac
- 9: https://support.huawei.com/enterprise/en/doc/EDOC1100410565/196277eb/zero-touch-device-deployment
- 10: https://support.huawei.com/enterprise/en/doc/EDOC1100333876/4175bdf0/configuring-an-as
- 11: https://www.intel.com/content/www/us/en/products/sku/52276/intel-xeon-processor-e31270-8m-cache-3-40-ghz/ordering.html
- 12: https://www.advantech.com/es-es/products/74040144-3f21-4a2c-b01e-dcadd0778058/ecu-1270/mod_5c264c06-99dc-4094-a74b-1f0ea881d960
🌐 Web query:
"osac-project" "target version" "version" "Jira"
💡 Result:
In the context of the osac-project (OpenShift Automation Components), the "target version" in Jira refers to a release version field used by the project's CI/CD automation to track and validate pull requests against specific milestones [1][2][3][4]. When developers submit pull requests to the project's repositories (such as osac-operator or osac-aap), the CI system checks the associated Jira issue [1][3]. If an issue is missing a "target version" (e.g., "5.0.0") or if the provided target version does not match the expected milestone for the branch being targeted by the pull request, the automated system will generate a warning or error message [1][2][3][4]. These Jira issues are typically managed on the Red Hat Jira instance (redhat.atlassian.net) and integrated via tools like the openshift-eng/jira-lifecycle-plugin, which ensures that development work is properly aligned with release versioning and project milestones [1][2][3].
Citations:
- 1: OSAC-2174: Trigger container image build on version tag pushes osac-operator#342
- 2: OSAC-1960: Add GitHub Release creation to publish-charts workflow osac-operator#335
- 3: OSAC-2185: Gate chart publish on image build success osac-aap#416
- 4: OSAC-2186: Pin configAsCode.eeImage/projectGitBranch at release osac-aap#412
Set the Jira target version to 5.0.0.
The PRD contains jira_key: OSAC-1270, but OSAC-1270 needs a Jira target version configured for the target branch. Set it to 5.0.0 before merging.
🤖 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/OSAC-1270-base-os-management/prd.md` around lines 2 - 5, Update
the OSAC-1270 PRD metadata to set the Jira target version to 5.0.0, preserving
the existing prd_id, title, jira_key, and status fields.
|
|
||
| ## In Scope | ||
|
|
||
| - A BaremetalInstance must have an effective DiskImage reference at creation time — either explicitly selected by the user or defaulted from the BaremetalInstanceCatalogItem. Creation is rejected when neither provides a reference. The instance is provisioned with the OS from that image. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Define precedence when both image inputs are supplied.
Specify whether an explicitly selected DiskImage overrides the catalog default or whether conflicting values are rejected. Without this rule, identical provisioning requests can resolve to different OS images depending on 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/OSAC-1270-base-os-management/prd.md` at line 23, Update the
BaremetalInstance creation requirement to explicitly define precedence when both
user-selected and catalog-default DiskImage references are present; specify
whether the explicit DiskImage overrides the catalog default or conflicting
values are rejected, and ensure the provisioning behavior follows that rule.
| - A BaremetalInstance must have an effective DiskImage reference at creation time — either explicitly selected by the user or defaulted from the BaremetalInstanceCatalogItem. Creation is rejected when neither provides a reference. The instance is provisioned with the OS from that image. | ||
| - DiskImage deletion is blocked when any BaremetalInstance (in any non-deleted state) or any BaremetalInstanceCatalogItem references it — applied to both global and tenant-scoped DiskImages. | ||
| - UI/API support for selecting and resolving eligible DiskImages during bare-metal instance creation; DiskImage browsing, lifecycle management, and lifecycle UI are defined by OSAC-2540. | ||
| - E2E test coverage for DiskImage selection at bare-metal instance provision time, added to the existing bare-metal test suite. | ||
| - DiskImages for bare-metal instances reuse the same resource, metadata schema, image source format, and two-tier visibility model (global + tenant-scoped) as defined in OSAC-2540. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Use the canonical BareMetal resource names.
The upstream API contract uses BareMetalInstance and BareMetalInstanceCatalogItem, but this PRD consistently uses BaremetalInstance and BaremetalInstanceCatalogItem. Align the terminology throughout the document to prevent ambiguity between the PRD and public API resources.
Also applies to: 34-35, 41-42, 50-51, 55-55, 60-60, 64-68
🤖 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/OSAC-1270-base-os-management/prd.md` around lines 23 - 27,
Update the PRD terminology throughout to use the canonical resource names
BareMetalInstance and BareMetalInstanceCatalogItem, replacing every occurrence
of BaremetalInstance and BaremetalInstanceCatalogItem while preserving the
documented behavior and references.
| - UI/API support for selecting and resolving eligible DiskImages during bare-metal instance creation; DiskImage browsing, lifecycle management, and lifecycle UI are defined by OSAC-2540. | ||
| - E2E test coverage for DiskImage selection at bare-metal instance provision time, added to the existing bare-metal test suite. | ||
| - DiskImages for bare-metal instances reuse the same resource, metadata schema, image source format, and two-tier visibility model (global + tenant-scoped) as defined in OSAC-2540. |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Make DiskImage eligibility enforceable in the acceptance criteria.
“Eligible” should explicitly cover the OSAC-2540 visibility and lifecycle rules: global or same-tenant images only, and obsolete images blocked from new provisioning, with deprecated-image behavior matching OSAC-2540. Otherwise an implementation could satisfy these criteria while allowing cross-tenant or obsolete images.
Also applies to: 64-69
🤖 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/OSAC-1270-base-os-management/prd.md` around lines 25 - 27,
Update the DiskImage selection and provisioning acceptance criteria to enforce
OSAC-2540 eligibility: allow only globally visible or same-tenant images, block
obsolete images from new bare-metal provisioning, and preserve OSAC-2540
behavior for deprecated images. Apply the same eligibility requirements to the
related criteria at the additional referenced section.
| - [ ] BaremetalInstance creation fails with a clear error when no DiskImage is specified and the BaremetalInstanceCatalogItem provides no default. | ||
| - [ ] A Cloud Provider Admin can create a BaremetalInstanceCatalogItem that references a global DiskImage as default. | ||
| - [ ] A Tenant Admin can create a BaremetalInstanceCatalogItem that references a tenant-scoped DiskImage as default. | ||
| - [ ] Deleting a DiskImage that is referenced by any BaremetalInstance or BaremetalInstanceCatalogItem is rejected. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Keep deletion protection consistent with the requirement.
The requirement limits blocking references to BareMetalInstances in non-deleted states, but this acceptance criterion says “any” BareMetalInstance. Add the non-deleted qualifier so deleted historical resources do not unintentionally prevent DiskImage deletion.
🤖 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/OSAC-1270-base-os-management/prd.md` at line 68, Update the
DiskImage deletion acceptance criterion to specify that deletion is rejected
only when referenced by BaremetalInstances or BaremetalInstanceCatalogItems that
are not deleted, allowing references from deleted historical resources.
ItzikEzra-rh
changed the title
|
@ItzikEzra-rh: No Jira issue is referenced in the title of this pull request. 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. |
2 participants
Summary
How this PRD was generated
This PRD was generated using the
prd.createskill from theosac-ai-skillspipeline (installed atosac-workspace/osac-ai-skills/).The skill is a non-interactive, autonomous PRD generator that:
scripts/fetch_feature.pyskills/prd-creator/context/skills/prd-creator/prompts/generate-prd.mdto produce the PRDscripts/score_prd.pySkill entry point:
osac-ai-skills/skills/prd-creator/SKILL.mdAll three checks passed (structure, personas, leakage). The skill is distinct from the interactive
prd:ingest→prd:clarify→prd:draftflow from ai-workflows, which asks clarifying questions before drafting.Assisted-by: Claude Code noreply@anthropic.com
Summary by CodeRabbit