Skip to content

Fix foundation plugin catalog source migration names#507

Merged
maorfr merged 3 commits into
mainfrom
fix/foundation-plugin-migration-catalog-names
Jun 16, 2026
Merged

Fix foundation plugin catalog source migration names#507
maorfr merged 3 commits into
mainfrom
fix/foundation-plugin-migration-catalog-names

Conversation

@maorfr

@maorfr maorfr commented Jun 16, 2026

Copy link
Copy Markdown
Collaborator

Summary

Fixes the foundation plugin catalog source migration to use correct catalog source names.

Problem

The 0.1.0 to 0.1.1 upgrade migration was failing to migrate foundation plugin operator subscriptions because:

  1. legacy_source was wrong: Used cs-mirror-redhat-operators-v4-20 but 0.1.0 actually used cs-redhat-operator-index-v4-20. example: https://github.com/rh-ecosystem-edge/enclave/blob/0.1.0/plugins/lvms/plugin.yaml#L13
  2. new_source was wrong: Used undefined catalog_mirror variable and incorrect format
  3. Migrated all catalogs: Attempted to migrate certified catalog plugins which use different sources

Changes

  • Hard-code legacy_source to cs-redhat-operator-index-v4-20 (actual 0.1.0 catalog source name)
  • Fix new_source to cs-{{ mirror_rh_operator_catalog }}-{{ plugin.name }}-v4-20 (e.g., cs-mirror-redhat-operators-lvms-v4-20)
  • Only migrate redhat catalog plugins by adding plugin.catalog | default('redhat') == 'redhat' condition

Test plan

  • Tested in RHDP disconnected environment during 0.1.0 → 0.1.1 upgrade
  • Migration now correctly identifies and updates LVMS and ODF operator subscriptions

References

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Chores
    • Updated migration task configuration for plugin operator subscriptions to improve catalog source handling and add additional validation conditions for proper execution.

The migration was failing to find subscriptions because:
- legacy_source incorrectly used "cs-mirror-redhat-operators-v4-20"
  instead of "cs-redhat-operator-index-v4-20" (the actual 0.1.0 name)
- new_source used an undefined catalog_mirror variable and incorrect format

Changes:
- Hard-code legacy_source to "cs-redhat-operator-index-v4-20"
- Fix new_source to "cs-{{ mirror_rh_operator_catalog }}-{{ plugin.name }}-v4-20"
- Only migrate redhat catalog plugins (exclude certified catalog)

This allows subscriptions to correctly migrate from cs-redhat-operator-index-v4-20
to plugin-specific sources like cs-mirror-redhat-operators-lvms-v4-20.

Assisted-by: Claude Code <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Jun 16, 2026

Copy link
Copy Markdown

Review Change Stack

Walkthrough

The migration task for foundation plugin operator subscriptions replaces dynamic catalog_mirror-based source selection with a fixed legacy catalog source (cs-redhat-operator-index-v4-20) and a new source built from mirror_rh_operator_catalog plus the plugin name. An explicit plugin.catalog == 'redhat' gate is added alongside the existing operator.source undefined check.

Changes

Foundation Plugin Catalog Source Migration

Layer / File(s) Summary
Migration variables and execution conditions
playbooks/tasks/migrations/foundation_plugin_catalog_sources.yaml
legacy_source is hardcoded to cs-redhat-operator-index-v4-20; new_source is templated as cs-{{ mirror_rh_operator_catalog }}-{{ plugin.name }}-v4-20; the when block adds (plugin.catalog | default('redhat')) == 'redhat' alongside the existing operator.source undefined guard.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Possibly related PRs

  • rh-ecosystem-edge/enclave#501: Modifies the same foundation_plugin_catalog_sources.yaml migration task, changing the included task file reference within the same migration flow.
  • rh-ecosystem-edge/enclave#461: Alters the same Ansible migration logic rewriting subscription spec.source from a legacy catalog to a new plugin-specific catalog source, with conditional gating on operator.source and Red Hat catalog.
  • rh-ecosystem-edge/enclave#309: Updates operator catalog/source selection logic transitioning from the hardcoded legacy cs-redhat-operator-index-v4-20 source toward mirror_rh_operator_catalog-based templating — directly related to the source name constants modified here.

Suggested labels

operators, plugins

Suggested reviewers

  • rporres

Poem

⚠️ The legacy source is locked in place,
cs-redhat-operator-index-v4-20 fixed in its space.
A redhat gate now guards the door —
unauthorized catalogs slide no more.
The migration hardens, scope is tight,
attack surface narrows; all is right. 🔐

🚥 Pre-merge checks | ✅ 11
✅ Passed checks (11 passed)
Check name Status Explanation
Title check ✅ Passed The title 'Fix foundation plugin catalog source migration names' directly and accurately summarizes the main change in the pull request, which is correcting the catalog source names used in the migration task.
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 found. Hardcoded values are public catalog source identifiers (cs-redhat-operator-index-v4-20, etc.), not credentials, API keys, tokens, passwords, or sensitive data.
No-Weak-Crypto ✅ Passed No weak crypto usage detected. This PR modifies infrastructure/migration YAML tasks containing no cryptographic code, weak algorithms, or unsafe secret comparisons.
No-Injection-Vectors ✅ Passed No injection vectors detected. The PR introduces safe variable interpolation in Ansible with admin-controlled and structured data sources, used only for Kubernetes API operations.
Container-Privileges ✅ Passed The modified file (playbooks/tasks/migrations/foundation_plugin_catalog_sources.yaml) is an Ansible playbook task file that performs database/catalog source migrations. It contains no container or...
No-Sensitive-Data-In-Logs ✅ Passed PR introduces no new logging that exposes sensitive data. Only non-sensitive catalog source identifiers and operator names are logged via existing debug task.
Ai-Attribution ✅ Passed AI tool usage (Claude Code) is properly attributed with "Assisted-by: Claude Code noreply@anthropic.com" trailer in commit message, meeting Red Hat attribution standards.
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/foundation-plugin-migration-catalog-names

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

Comment @coderabbitai help to get the list of available commands and usage tips.

maorfr added 2 commits June 16, 2026 14:43
Remove complex ternary logic for catalog selection and only handle
redhat catalog foundation plugins (LVMS, ODF). Certified catalog
plugins like vast-csi are excluded from this migration.

Changes:
- Replace ternary catalog selection with direct redhat catalog variables
- Add when condition to filter for redhat catalog plugins only
- Simplifies catalog_image, catalog_mirror, and catalog_version vars

Assisted-by: Claude Code <noreply@anthropic.com>
Use plugin.catalog instead of fleet_plugin.catalog to match the
vars block where plugin is defined.

Assisted-by: Claude Code <noreply@anthropic.com>
@maorfr

maorfr commented Jun 16, 2026

Copy link
Copy Markdown
Collaborator Author

success indicated via slack

@maorfr maorfr merged commit de12088 into main Jun 16, 2026
21 of 22 checks passed
@maorfr maorfr deleted the fix/foundation-plugin-migration-catalog-names branch June 16, 2026 12:36

@rporres rporres left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, I tested this RHDP and works fine

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants