Uploaded image for project: 'Red Hat Workload Availability'
  1. Red Hat Workload Availability
  2. RHWA-215

Refactor FBC Catalogs to Use a Shared Configuration

XMLWordPrintable

    • Icon: Task Task
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • None
    • rhwa

      Currently, we maintain separate File-Based Catalogs (FBC) for each supported OCP version (e.g., OCP 4.14-4.19 etc.). Each of these catalog directories contains its own graph.yaml and catalog.yaml files.

      The content of graph.yaml (the operator update graph) and catalog.yaml (the catalog metadata) is largely identical across all OCP versions. This duplication leads to several problems:

      • High Maintenance Overhead: When adding a new operator version or defining a new upgrade path, the same change must be manually replicated in multiple graph.yaml files.
      • Risk of Inconsistency: It is easy to make a mistake or forget to update one of the catalogs, leading to different upgrade paths on different OCP versions.
      • Violates DRY Principle: We are not following the "Don't Repeat Yourself" principle, which makes our process inefficient.

      2. Proposed Solution

      We will refactor our catalog structure to use a single, centralized source of truth for the catalog configuration in a common repo - Tools.

      • Create one common graph.yaml that defines the complete update graph for our operator.
      • Create one common catalog.yaml that defines the static metadata for our catalog.
      • Modify the build process for each OCP-specific FBC to reference or copy these centralized files when generating the final catalog image.

      This change will mean that the catalog for OCP 4.14 and the catalog for OCP 4.16 will both be built from the same graph.yaml, ensuring consistency.

       

      Acceptance Criteria:

      • A single, master graph.yaml file exists in a common, shared directory in the repository.
      • A single, master catalog.yaml file exists in a common, shared directory.
      • The build scripts/process for all OCP-specific catalogs are updated to use these shared files.
      • The old, duplicated graph.yaml and catalog.yaml files are removed from the OCP-specific directories.
      • The build process for all catalogs completes successfully after the changes.
      • An operator installed from a newly built catalog on a target OCP cluster installs successfully and shows the correct upgrade path in OLM.

              rh-ee-slevi Shai Shimon Levi
              rh-ee-slevi Shai Shimon Levi
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: