OSAC-1828: add ocp_small cluster template seed with OCP 4.22 default

[tzvatot]

OSAC-1828: Add ocp_small cluster template seed with OCP 4.22 default

Jira: OSAC-1828

Summary

Adds a new ocp_small cluster template to the database with a parameterized ocp_release_version (default 4.22.0) and specDefaults.releaseImage set to the OCP 4.22 multi-arch release image. This is Phase 1 of a non-breaking approach to update the default CaaS cluster OCP version - the existing ocp_4_17_small template is not modified.

Companion PR: osac-project/osac-aap - adds the corresponding ocp_small Ansible role.

Changes

• New migration 68_add_ocp_small_cluster_template.up.sql inserting the ocp_small template with:
  • ocp_release_version string parameter (default "4.22.0")
  • specDefaults.releaseImage = quay.io/openshift-release-dev/ocp-release:4.22.0-multi
  • Assigned to the shared tenant
• Updated migrations.sha256 hash
• Migration test verifying seed data content and tenant assignment

Testing

• Unit tests: 2 new migration tests (68_add_ocp_small_cluster_template_test.go)
• Integration tests: N/A
• Coverage: Full database test suite (94 specs) passes including migration runtime against PostgreSQL

Acceptance Criteria

• DB seed includes the new ocp_small template
• Cluster CR default release_image updated to 4.22 (via specDefaults.releaseImage)
• ocp_4_17_small template remains functional (not modified)

Summary by CodeRabbit

• New Features

  • Added a new ocp_small cluster template option for shared tenants.
  • The template includes a default OpenShift release version and preconfigured release image settings.

• Tests

  • Added coverage to verify the new template is created with the expected details and tenant assignment.

[openshift-ci-robot]

@tzvatot: This pull request references OSAC-1828 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.

Details

In response to this:

OSAC-1828: Add ocp_small cluster template seed with OCP 4.22 default

Jira: OSAC-1828

Summary

Adds a new ocp_small cluster template to the database with a parameterized ocp_release_version (default 4.22.0) and specDefaults.releaseImage set to the OCP 4.22 multi-arch release image. This is Phase 1 of a non-breaking approach to update the default CaaS cluster OCP version - the existing ocp_4_17_small template is not modified.

Companion PR: osac-project/osac-aap - adds the corresponding ocp_small Ansible role.

Changes

• New migration 68_add_ocp_small_cluster_template.up.sql inserting the ocp_small template with:
• ocp_release_version string parameter (default "4.22.0")
• specDefaults.releaseImage = quay.io/openshift-release-dev/ocp-release:4.22.0-multi
• Assigned to the shared tenant
• Updated migrations.sha256 hash
• Migration test verifying seed data content and tenant assignment

Testing

• Unit tests: 2 new migration tests (68_add_ocp_small_cluster_template_test.go)
• Integration tests: N/A
• Coverage: Full database test suite (94 specs) passes including migration runtime against PostgreSQL

Acceptance Criteria

• DB seed includes the new ocp_small template
• Cluster CR default release_image updated to 4.22 (via specDefaults.releaseImage)
• ocp_4_17_small template remains functional (not modified)

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.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: tzvatot

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [tzvatot]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[coderabbitai]

Warning

Review limit reached

@tzvatot, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 33 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 @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Repository: osac-project/coderabbit/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Enterprise

Run ID: a61f8ac8-d88e-4481-b016-f418d7dce4a5

📥 Commits

Reviewing files that changed from the base of the PR and between 406c84b and 9fd18d5.

📒 Files selected for processing (3)

• internal/database/migrations.sha256
• internal/database/migrations/68_add_ocp_small_cluster_template.up.sql
• internal/database/migrations/68_add_ocp_small_cluster_template_test.go

Walkthrough

Migration 71 inserts an ocp_small cluster template into cluster_templates for the shared tenant, with a JSON payload defining an ocp_release_version parameter (default 4.22.0) and specDefaults.releaseImage set to 4.22.0-multi. A Ginkgo test verifies both the JSON content and tenant assignment. The migrations SHA-256 checksum is updated accordingly.

Migration 71: ocp_small cluster template

Layer / File(s)	Summary
SQL migration and verification test internal/database/migrations/71_add_ocp_small_cluster_template.up.sql, internal/database/migrations/71_add_ocp_small_cluster_template_test.go, internal/database/migrations.sha256	Inserts ocp_small template row with JSON metadata, ocp_release_version parameter defaulting to 4.22.0, and specDefaults.releaseImage pointing to 4.22.0-multi. Test asserts the full JSON shape and shared tenant assignment. SHA-256 checksum updated to reflect new migration file.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

Possibly related PRs

• osac-project/fulfillment-service#747: Introduced the SHA-256 hash-verification mechanism that migrations.sha256 feeds into, which this PR updates.
• osac-project/fulfillment-service#774: Also updates only internal/database/migrations.sha256 to a new checksum, the same file modified here.

Poem

A small cluster template joins the fold,
ocp_small with release image bold,
Version 4.22.0 set as default today,
SHA-256 updated, checksums hooray! 🎉
The shared tenant welcomes its new guest to stay.

🚥 Pre-merge checks | ✅ 11

✅ Passed checks (11 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: adding the ocp_small cluster template seed with the OCP 4.22 default.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
No-Hardcoded-Secrets	✅ Passed	No hardcoded secrets, tokens, passwords, private keys, or embedded credentials appear in the modified files.
No-Weak-Crypto	✅ Passed	Touched files only add a seed migration, test, and a SHA-256 checksum update; no MD5/SHA1/DES/RC4/ECB/custom crypto or secret comparisons found.
No-Injection-Vectors	✅ Passed	The new SQL and Go test use only static literals; no user-controlled concatenation or dangerous APIs appear.
Container-Privileges	✅ Passed	No container/K8s manifests changed; PR only touches SQL seed, hash, and Go test files, with no privilege settings present.
No-Sensitive-Data-In-Logs	✅ Passed	The PR adds only SQL seed data and a test; there are no new log statements or sensitive identifiers exposed in logs.
Ai-Attribution	✅ Passed	PASS: The commit includes Assisted-by: Claude Code and no Co-Authored-By trailer is present.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 2

🤖 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/database/migrations/71_add_ocp_small_cluster_template_test.go`:
- Around line 60-66: The test is still querying the wrong tenancy field, so
update the assertion in the migration test to validate the
cluster_templates.tenants array instead of tenant. Use the existing test block
around row.Scan in 71_add_ocp_small_cluster_template_test.go and make the
query/scan/assertion match the schema contract from migration 11 so it checks
the actual array value on the ocp_small template.

In `@internal/database/migrations/71_add_ocp_small_cluster_template.up.sql`:
- Around line 14-18: Update the `cluster_templates` seed in the
`71_add_ocp_small_cluster_template` migration to use the schema’s `tenants`
field instead of `tenant`, or omit the field if the default should apply. Make
the same adjustment in the related test that validates this seed so it asserts
against `tenants` on the `cluster_templates` record, keeping the migration and
test aligned with the existing tenancy contract.

🪄 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: 27dcf894-a2f8-411f-9be4-e639495fb47f

📥 Commits

Reviewing files that changed from the base of the PR and between b250664 and 406c84b.

📒 Files selected for processing (3)

• internal/database/migrations.sha256
• internal/database/migrations/71_add_ocp_small_cluster_template.up.sql
• internal/database/migrations/71_add_ocp_small_cluster_template_test.go

[tzvatot]

/retest

[github-actions]

Re-triggered failed runs:

• E2E VMaaS Full Install (#28440926458)

[AlonaKaplan]

Why is a migration needed to add a new cluster template?

ClusterTemplates already has a full CRUD API (Create, Get, List, Update, Delete) on both public and private services. A new template like ocp_small should be registered through the API — not inserted directly into the database via a migration script.

Moreover, this infrastructure already exists in osac-aap. The publish_templates role (osac.service.publish_templates) handles exactly this:

1. enumerate_templates scans Ansible collection roles for meta/osac.yaml and discovers templates automatically
2. publish_templates GETs existing templates from /api/private/v1/cluster_templates, PATCHes existing ones, POSTs new ones
3. This runs on a 30-minute AAP schedule and is also triggered during bootstrap via osac-installer/scripts/prepare-fulfillment-service.sh

The companion osac-aap PR (#385) already adds the ocp_small role with meta/osac.yaml — the publish_templates pipeline will automatically discover it and register it via the API. This migration is duplicating what the existing infrastructure already handles.

The migration approach also means every new template requires a code change, PR, and release cycle in fulfillment-service. A cloud provider adding a custom template shouldn't need to touch the DB.

Maybe I'm missing something, but this PR shouldn't be needed at all — just the osac-aap PR adding the role.

[tzvatot]

Why is a migration needed to add a new cluster template?

Correct. I was wrong - closing this.