OSAC-1531: PRD - Default Catalog Items - #129
danielerez wants to merge 5 commits into
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: danielerez 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 |
|
Warning Review limit reached
Next review available in: 49 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)
WalkthroughChangesThe PRD defines default cluster and VM catalog items, metadata-driven enumeration and publishing, installation-time wiring, global tenant visibility, acceptance criteria, deployment prerequisites, and unresolved implementation questions. Default Catalog Items
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-129Score: 9/10 | Verdict: PASS
Verdict: A strong, well-structured PRD with clear user need and concrete justification; the only weakness is minor design leakage (repo paths, internal template names) and acceptance criteria that mix product-verifiable outcomes with engineering file-existence checks. Feedback: Rewrite acceptance criteria to focus on product-observable outcomes rather than repo file existence — e.g., 'After running the documented loading procedure, 6 catalog items (2 cluster, 4 VM) are visible via the public API' instead of 'YAML files exist in examples/catalog-items/'. Remove or relocate the repo path references (examples/catalog-items/ in fulfillment-service) to keep the PRD user-focused; the implementation location belongs in the design document. Consider replacing the internal template reference (osac.templates.ocp_4_17_small) with a user-facing description of what the template represents. 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: 3
🤖 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/default-catalog-items/prd.md`:
- Line 19: Update the default catalog item acceptance criteria to verify global
publication semantics for every item: assert tenant is empty, the item is
published, and Tenant Users can discover it through the public List behavior,
CLI, and UI, rather than only confirming creation or API response.
- Line 43: Update the default catalog item requirements in the PRD to define
concrete field acceptance criteria for all six YAML files: enumerate each
provisioning-consumed field path, its metadata, default where applicable,
validation schema, and whether disk size and network CIDR are mandatory. Remove
ambiguous wording and ensure the requirements are testable without adding
unsupported fields.
- Around line 17-18: Update the PRD’s dependency or acceptance-criteria sections
to explicitly define the required OpenShift release, VM template IDs, and image
references for the default catalog items, or narrow acceptance to catalog
visibility after seeding. Also state whether the unresolved prerequisite
question blocks the 0.2 milestone, while keeping the listed catalog items
unchanged.
🪄 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: f9964a12-3d08-4557-9526-ca63e76a6554
📒 Files selected for processing (1)
enhancements/default-catalog-items/prd.md
AI EP Review: EP-129Score: 10/10 | Verdict: PASS
Verdict: Well-structured PRD with clear user outcomes, concrete business justification, specific acceptance criteria, and focused scope — a strong example of a user-facing requirements document. Feedback: This is a solid PRD. For minor improvement, consider specifying which exact fields are user-editable on each catalog item type (the current phrasing 'e.g., disk size, network CIDR' leaves the field list open-ended for the design phase, which is acceptable but could be more precise). The open question on image pre-loading strategy is well-framed and correctly identified as non-blocking. Critical (0)None. Important (0)None. Suggestions (2)
Review costModel: claude-opus-4-6 |
danielerez
changed the title
|
@danielerez: This pull request references OSAC-1531 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. |
|
Unless I missed something, this isn't a feature - it's example content. The PRD proposes writing YAML files and a README, putting them in The problem statement contradicts the solution. The PRD says the pain is: "a Cloud Provider Admin must manually define every catalog item before tenants can order any resources." The proposed fix: the admin manually runs The dependencies make it worse. The PRD acknowledges that VM images (RHEL, Windows) and OpenShift artifacts must be separately available before any of these catalog items actually work. Since OSAC doesn't ship those images or releases, loading the default catalog items on a fresh deployment gives you a catalog full of items that can't provision anything. "Tenants can immediately browse and order resources" is misleading - they can browse, but ordering will fail until someone separately loads the backing images. What should happen instead: This work is fine as a Jira task - "write example catalog item YAML files and a README with loading instructions." It doesn't need a PRD that flows into a design document. That pipeline is for product capabilities that require design decisions. Writing example YAML files requires content decisions (which catalog items, what resource defaults), not architecture. |
Sure, just assumed we still want a PRD for this (https://redhat.atlassian.net/browse/OSAC-2603). |
AI EP Review: EP-129Score: 10/10 | Verdict: PASS
Verdict: A strong, well-structured PRD that clearly describes a user-facing improvement with concrete justification, identified personas, specific acceptance criteria, and focused scope. Feedback: Minor improvements: (1) Move repository paths like Critical (0)None. Important (0)None. Suggestions (3)
Review costModel: claude-opus-4-6 |
No worries, not your fault - the feature shouldn't have existed in the first place. I also recommend skipping the subcommand in |
|
Overhauled the PRD: replaced static YAML examples with an infrastructure-as-code approach where catalog items are defined in osac-aap template roles (meta/catalog.yaml) and published automatically during installation, mirroring the existing publish_templates pipeline. |
AI EP Review: EP-129Score: 8/10 | Verdict: PASS
Verdict: A solid PRD with clear user outcomes and focused scope, held back by pervasive design leakage in the In Scope and Acceptance Criteria sections and a business justification that describes the gap without quantifying its impact. Feedback: Rewrite the In Scope section to describe user-observable outcomes rather than internal roles, file paths, and playbook patterns — move implementation details (enumerate_catalog_items role, meta/catalog.yaml schema, Pydantic validation, Helm hook-weight ordering) to the design document. Strengthen the WHY by quantifying the friction: how long does manual catalog setup take, has this blocked specific demos or onboarding, how many fresh deployments are affected? Refactor acceptance criteria to be verifiable by a PM using the product — replace items like 'filter plugin validates against a Pydantic model' with observable outcomes like 'malformed catalog metadata produces a clear error in the publishing job log.' Critical (0)None. Important (3)
Suggestions (2)
Review costModel: claude-opus-4-6 |
Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Daniel Erez <danielerez@gmail.com>
- Tighten acceptance criteria to explicitly verify global publication semantics (no tenant scope, visible via public List/CLI/UI) - Clarify that the open question on image pre-loading does not block 0.2 - Sharpen field definition AC wording for testability Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Daniel Erez <danielerez@gmail.com>
Rewrite from static YAML examples approach to infrastructure-as-code catalog items in osac-aap, published automatically alongside templates via AAP job and Helm post-install hook. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Daniel Erez <danielerez@gmail.com>
Rename enhancements/default-catalog-items to enhancements/OSAC-1531-default-catalog-items to match the required OSAC-<jira-key>-<slug> format. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Daniel Erez <danielerez@gmail.com>
AI EP Review: EP-129Score: 9/10 | Verdict: PASS
Verdict: Strong PRD with clear user need, concrete business justification, and well-scoped feature boundaries, held back from a perfect score by significant design leakage in the In Scope and acceptance criteria sections. Feedback: The In Scope section prescribes implementation details that belong in the design document — specific AAP role names, file paths (meta/catalog.yaml), Helm hook-weight ordering, and the GET/PATCH/POST upsert pattern. Rewrite In Scope as user-observable capabilities (e.g., 'default catalog items are automatically published during installation and updated during upgrades') and move implementation choices to the EP. Similarly, acceptance criteria like 'the enumerate_catalog_items filter plugin validates against a Pydantic model' are internal — reframe as 'invalid catalog item definitions are rejected with actionable error messages during publishing.' Critical (0)None. Important (2)
Suggestions (2)
Review costModel: claude-opus-4-6 |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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/default-catalog-items/prd.md`:
- Around line 57-62: Update the catalog-item publishing requirements in the PRD
to define the immutable identity key used by GET/PATCH/POST upserts, and specify
that reruns locate items by this key while applying changes to mutable metadata
such as name or title without creating duplicates.
- Line 56: Update the acceptance criterion for enumerate_catalog_items to remove
bare metal instance objects from this milestone, while retaining cluster and
compute instance typed objects; alternatively, explicitly scope the criterion to
generic enumeration without bare-metal metadata or publication.
- Line 55: Update the acceptance criterion in the default catalog items PRD to
require all four catalog items: SNO, compact OpenShift, general-purpose Linux
VM, and GPU-enabled Linux VM, each represented by the relevant cluster or
compute instance template role with a meta/catalog.yaml file.
🪄 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: 11417adc-4d70-44ea-ade3-25c8f17d82f7
📒 Files selected for processing (1)
enhancements/default-catalog-items/prd.md
| ### Acceptance Criteria | ||
|
|
||
| - [ ] A `meta/catalog.yaml` schema is defined and documented, supporting catalog item fields: `name`, `title`, `description`, `published`, and `field_definitions` (with `name`, `title`, `description`, `type`, `default`, `editable`, and `validation`) | ||
| - [ ] At least one cluster template role and one compute instance template role include a `meta/catalog.yaml` file defining default catalog items |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Require all four default catalog items.
“At least one” cluster and compute role permits an implementation that omits the compact cluster and GPU VM, despite both being in scope. Require SNO, compact OpenShift, general-purpose Linux VM, and GPU-enabled Linux VM in acceptance coverage.
🤖 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/default-catalog-items/prd.md` at line 55, Update the acceptance
criterion in the default catalog items PRD to require all four catalog items:
SNO, compact OpenShift, general-purpose Linux VM, and GPU-enabled Linux VM, each
represented by the relevant cluster or compute instance template role with a
meta/catalog.yaml file.
|
|
||
| - [ ] A `meta/catalog.yaml` schema is defined and documented, supporting catalog item fields: `name`, `title`, `description`, `published`, and `field_definitions` (with `name`, `title`, `description`, `type`, `default`, `editable`, and `validation`) | ||
| - [ ] At least one cluster template role and one compute instance template role include a `meta/catalog.yaml` file defining default catalog items | ||
| - [ ] An `enumerate_catalog_items` role discovers `meta/catalog.yaml` files from template role directories and produces typed catalog item objects (cluster, compute instance, bare metal instance) |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Align the acceptance criterion with the stated scope.
Bare metal catalog items are explicitly out of scope, but this criterion requires bare-metal typed objects. Remove that type for this milestone, or clarify that only generic enumeration support is required and no bare-metal metadata or publication is delivered.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~56-~56: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...tem objects (cluster, compute instance, bare metal instance) - [ ] A `publish_catalog_item...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
🤖 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/default-catalog-items/prd.md` at line 56, Update the acceptance
criterion for enumerate_catalog_items to remove bare metal instance objects from
this milestone, while retaining cluster and compute instance typed objects;
alternatively, explicitly scope the criterion to generic enumeration without
bare-metal metadata or publication.
- Require all four default catalog items in acceptance criteria - Remove bare metal from enumerate_catalog_items scope Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Daniel Erez <danielerez@gmail.com>
221bc72 to
38ab6e8
Compare
| @@ -0,0 +1,114 @@ | |||
| # Default Catalog Items | |||
There was a problem hiding this comment.
This feels like a feature of Enclave. Imagine a wizard flow:
- Select RHEL versions that you'd like to load from a list
- Select OpenShift versions that you'd like to load from a list
- Select the instance types that you'd like to pre-create
Note that even with this the admin would still need to configure a storage backend, storage tiers, etc. so it still doesn't get us to being able to launch a workload immediately.
There was a problem hiding this comment.
This feels like a feature of Enclave. Imagine a wizard flow:
- Select RHEL versions that you'd like to load from a list
- Select OpenShift versions that you'd like to load from a list
- Select the instance types that you'd like to pre-create
Note that even with this the admin would still need to configure a storage backend, storage tiers, etc. so it still doesn't get us to being able to launch a workload immediately.
@AlonaKaplan @tzvatot @CrystalChun WDYT ^
Should we just settle on some examples in the codebase for now then? I.e. as done in: osac-project/fulfillment-service#724
There was a problem hiding this comment.
I'm ok with it. The idea is to have something useful post install so users can start creating clusters/VMs/BMs.
These yaml examples (or a CLI sub command if that's what will be used eventually) answers that purpose.
There was a problem hiding this comment.
Yaml examples sounds fine to me
AI EP Review: EP-129Score: 9/10 | Verdict: PASS
Verdict: A well-motivated PRD with clear user need and focused scope, held back by extensive design leakage in the In Scope and acceptance criteria sections that prescribe implementation rather than defining measurable user outcomes. Feedback: Move implementation details (Ansible role names, playbook names, meta/catalog.yaml schema, AAP job template names, Helm hook-weight ordering, Pydantic validation) from In Scope and acceptance criteria into the design document — the PRD should state what users and admins can observe, not which internal components deliver it. Rewrite acceptance criteria as PM-verifiable scenarios: 'After a fresh install, a tenant can list at least 4 catalog items (2 cluster, 2 VM) via the CLI or UI without any admin action' rather than 'An enumerate_catalog_items role discovers meta/catalog.yaml files.' Consider whether Tenant Admin needs coverage — they may need to see or manage catalog item visibility within their organization. Critical (0)None. Important (2)
Suggestions (2)
Review costModel: claude-opus-4-6 |
AI Design Review: EP-129Score: 1/8 | Verdict: FAIL
Verdict: This PR submits a PRD (prd.md), not a design document (design.md), so it fundamentally lacks the architectural detail, implementation specifics, and test plans that the design review rubric requires — resulting in three zero-scored criteria and an automatic fail. Feedback: The PRD itself is well-structured with clear problem statement, specific scope boundaries, and thoughtful open questions — but it is not a design document. To pass design review, a companion design.md is needed covering: proto schemas for catalog item metadata, the publish workflow with error handling and failure recovery, controller/reconciler integration details, tenant isolation annotations, RBAC analysis, and a concrete test plan with unit/integration/e2e scenarios. Additionally, the In Scope section leaks implementation details (Ansible role names, Helm hook weights, Pydantic models) that belong in the design, not the PRD — refactor these out per review-patterns.md guidance. Critical (3)
Important (4)
Suggestions (3)
Review costModel: claude-opus-4-6 |
|
|
||
| ## Out of Scope | ||
|
|
||
| - Bare metal catalog items: these depend on installation-specific inventory and are not generalizable as defaults |
There was a problem hiding this comment.
What are the issues? The BareMetailInstance spec is not specific to any inventory backends. InstanceTypes maybe an issue, as the cloud admin provider must curate them. (Note that might be the same issue with DiskImages: #145 (comment))
| **Impact:** `meta/catalog.yaml` schema | ||
|
|
||
| A single template role (e.g., `ocp_virt_vm`) may back multiple catalog items (e.g., "Linux VM" and "GPU Linux VM") with different field definition defaults. Should `meta/catalog.yaml` support a list of catalog item definitions, or should each catalog item be defined in a separate role directory? The list approach keeps related offerings together; separate roles give each catalog item its own task files. | ||
|
|
There was a problem hiding this comment.
Should template default spec values be deprecated/removed as catalog items will the source of truth for such information? https://redhat-internal.slack.com/archives/C08ESMFV85Q/p1784883619304099
There was a problem hiding this comment.
Hm. In what way do catalog items become the source of truth? They're supposed to be a presentation layer for templates. I would assume that the template is the thing that actually needs specific input parameters and thus would be the source of truth for defining the parameters and sensible defaults. Catalog Items of course can prescribe different values for specific parameters that are based on the circumstances and how a CSP wants to curate/present templates.
|
|
||
| OSAC automatically publishes infrastructure templates during installation via the `publish_templates` AAP job, but catalog items (the curated offerings tenants actually browse and order from) must be created manually by a Cloud Provider Admin after deployment. This means that after a fresh install, tenants see an empty catalog and cannot self-service until an admin has hand-crafted catalog items via the API or CLI. There is no code-driven mechanism to define, version, or automatically publish default catalog items, creating friction for new deployments, demos, and onboarding. | ||
|
|
||
| ## In Scope |
There was a problem hiding this comment.
There is a lot of implementation detail in this section, which should be saved for a design doc. For example, does the product require "A publish_catalog_items playbook in osac.service that chains enumeration and publishing, analogous to the existing publish_templates.yaml playbook" ? No. But the product probably requires a problem to be solved that the aforementioned example solves. In PRDs we should be focusing on the problem, not the solution.
| - **Services:** CaaS (cluster catalog items), VMaaS (VM catalog items) | ||
| - **Target milestone:** 0.2 | ||
|
|
||
| ## Out of Scope |
There was a problem hiding this comment.
I would add that maintaining or upgrading catalog items over time is out of scope. We can generate some "getting started" data that works out of the box, but expect the CSP to take ownership of it.
|
|
||
| - As a Cloud Provider Admin, I want default catalog items to be automatically published during platform installation so that tenants can browse and order resources immediately after deployment without manual catalog configuration. | ||
| - As a Cloud Provider Admin, I want to define custom catalog items as code in Ansible role metadata (`meta/catalog.yaml`) so that I can version-control, review, and customize the catalog offerings alongside the template definitions they reference. | ||
| - As a Cloud Provider Admin, I want the catalog item publishing to be idempotent (upsert semantics) so that rerunning the installer or upgrading the platform updates existing catalog items without creating duplicates. |
There was a problem hiding this comment.
WDYT about making the platform's creation of catalog items a 1-time activity during installation? It's a lot easier if we treat the initial catalog items as example data that gets a CSP started out-of-the-box, but assume they'll take ownership and customize them. We have to keep in mind that the CSP might not like the default catalog items, and is likely to modify or delete them. We don't want to be trying to merge our changes with theirs down the road.
| - As a Cloud Provider Admin, I want to define custom catalog items as code in Ansible role metadata (`meta/catalog.yaml`) so that I can version-control, review, and customize the catalog offerings alongside the template definitions they reference. | ||
| - As a Cloud Provider Admin, I want the catalog item publishing to be idempotent (upsert semantics) so that rerunning the installer or upgrading the platform updates existing catalog items without creating duplicates. | ||
|
|
||
| ### Tenant User |
There was a problem hiding this comment.
I don't think the tenant user necessarily plays any role in this feature. The CSP has to get their own service offerings in order before they invite their customers (tenants) to start using the system. If we include some default catalog items, that just helps the CSP.
The tenant doesn't care where the global catalog items came from.
| **Owner:** VMaaS / CaaS / Installer teams | ||
| **Impact:** Dependencies, installation workflow, usability on fresh deployments | ||
|
|
||
| Default catalog items reference VM container disk images and OpenShift release artifacts that must exist in the deployment environment before provisioning can succeed. Catalog items can be published and browsed without these artifacts, but ordering will fail until they are in place. How should these prerequisite artifacts be loaded into a fresh deployment? Options include a separate seeding job (similar to `publish_catalog_items`), documentation-only guidance, or integration with the installer. This feature documents the dependency but does not solve the preloading problem; the mechanism is tracked separately. |
There was a problem hiding this comment.
It's a reasonable idea to make the loading of default "example" data like this a discrete action that is both part of the installation and can be independently initiated later.
…comment thread) Follow-up to Eran Cohen's OSAC-2870 comment identifying resolvable Jira keys for 4 of the 8 remaining unrenamed directories, plus independent verification/correction of a 5th: - catalog-items -> OSAC-1002-catalog-items (NOT OSAC-1531 as originally suggested by directory-name similarity — verified via content: OSAC-1002's Jira description explicitly links PR #17, the exact PR that created this directory. OSAC-1531/PR #129's enhancements/OSAC-1531-default-catalog-items/ is a separate, later, narrower feature that assumes this catalog item API already exists — no actual duplication between the two.) - dns-api -> OSAC-1050-dns-api (dir + originating PR #29 both created 2026-03-17; problem statement nearly verbatim match; reporter Dan Manor = author dmanor) - organizations -> OSAC-1030-organizations (dir + originating PR #14 both created 2025-12-21; Jira explicitly links PR #14) - vm-api-fields -> OSAC-1034-vm-api-fields (dir + originating PR #21 both created 2026-01-27; parent Epic OSAC-61 authored by Michael Hrivnak = dir author mhrivnak) - repository-consolidation -> OSAC-1732-repository-consolidation (Epic-level key, not parent Feature OSAC-2053: OSAC-2053 is a broad 'CI Modernization & Quality' umbrella with 10 unrelated sibling Epics, while OSAC-1732's title is a word-for-word match of the EP's own title and Jira explicitly links PR #40, the exact originating PR. Also self-authored by Eran Cohen, who filed both.) Filled in tracking-link frontmatter for all 5 (previously empty/TBD). Updated 10 cross-references across 8 other files, including two hardcoded GitHub blob links in organizations/ui-design.md that pointed at the pre-rename path. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Tommy Hughes <tohughes@redhat.com>
|
Pushed some examples and docs to the codebase as discussed: osac-project/fulfillment-service#972 |
…comment thread) Follow-up to Eran Cohen's OSAC-2870 comment identifying resolvable Jira keys for 4 of the 8 remaining unrenamed directories, plus independent verification/correction of a 5th: - catalog-items -> OSAC-1002-catalog-items (NOT OSAC-1531 as originally suggested by directory-name similarity — verified via content: OSAC-1002's Jira description explicitly links PR osac-project#17, the exact PR that created this directory. OSAC-1531/PR osac-project#129's enhancements/OSAC-1531-default-catalog-items/ is a separate, later, narrower feature that assumes this catalog item API already exists — no actual duplication between the two.) - dns-api -> OSAC-1050-dns-api (dir + originating PR osac-project#29 both created 2026-03-17; problem statement nearly verbatim match; reporter Dan Manor = author dmanor) - organizations -> OSAC-1030-organizations (dir + originating PR osac-project#14 both created 2025-12-21; Jira explicitly links PR osac-project#14) - vm-api-fields -> OSAC-1034-vm-api-fields (dir + originating PR osac-project#21 both created 2026-01-27; parent Epic OSAC-61 authored by Michael Hrivnak = dir author mhrivnak) - repository-consolidation -> OSAC-1732-repository-consolidation (Epic-level key, not parent Feature OSAC-2053: OSAC-2053 is a broad 'CI Modernization & Quality' umbrella with 10 unrelated sibling Epics, while OSAC-1732's title is a word-for-word match of the EP's own title and Jira explicitly links PR osac-project#40, the exact originating PR. Also self-authored by Eran Cohen, who filed both.) Filled in tracking-link frontmatter for all 5 (previously empty/TBD). Updated 10 cross-references across 8 other files, including two hardcoded GitHub blob links in organizations/ui-design.md that pointed at the pre-rename path. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Tommy Hughes <tohughes@redhat.com>
7 participants
PRD: Default Catalog Items
Jira: https://redhat.atlassian.net/browse/OSAC-1531
Summary
OSAC automatically publishes infrastructure templates during installation, but catalog items (the curated offerings tenants browse and order from) must be created manually. This PRD proposes an infrastructure-as-code approach: catalog item definitions live as
meta/catalog.yamlmetadata alongside template roles inosac-aap, discovered and published automatically via a new AAP job and Helm post-install hook, mirroring the existingpublish_templatespipeline.Default catalog items: 2 cluster (SNO, compact OpenShift) and 2 VM (Linux general-purpose, GPU-enabled Linux).
Requesting Review On
meta/catalog.yamlapproach (colocated with template roles) is the right patternHow to Review
Summary by CodeRabbit