Uploaded image for project: 'OpenShift Top Level Product Strategy'
  1. OpenShift Top Level Product Strategy
  2. OCPPLAN-7759

Add support for specifying which CatalogSource to use for the OLM dependencies

XMLWordPrintable

    • Icon: Feature Feature
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • None
    • False
    • False
    • ?
    • No
    • ?
    • ?
    • ?
    • Undefined

      Currently, there's no way to specify where the dependecies are coming from. Given the current dependencies resolution mechanism, dependencies can be injected in the resolution tree by creating a CatalogSource with higher priority containing an operator with the same name. That's unsafe for Managed Services.

      The only way around is to add the bundles of all the dependencies into the same catalog as the main operator, but that creates duplication and overhead for the Managed Services teams. Also, considering the dependencies might also have their dependencies, using this workaround pretty much means duplicating the content of all the catalogs in each operator's catalog.

      Acceptance criteria:

      • OLM dependencies should allow the specification of the CatalogSource to use for each dependency.

       

            [OCPPLAN-7759] Add support for specifying which CatalogSource to use for the OLM dependencies

            Amador Pahim Segundo (Inactive) added a comment -

            > What about an option at the Subscription level to constrain the dependency resolution scope to the catalog of the original operator?

            That works for us

            Amador Pahim Segundo (Inactive) added a comment - > What about an option at the Subscription level to constrain the dependency resolution scope to the catalog of the original operator? That works for us

            Daniel Messer added a comment -

            Most of these sounds like pretty complex, big hammers. What about an option at the Subscription level to constrain the dependency resolution scope to the catalog of the original operator?

            Daniel Messer added a comment - Most of these sounds like pretty complex, big hammers. What about an option at the Subscription level to constrain the dependency resolution scope to the catalog of the original operator?

            Josh Gwosdz added a comment -

            rhn-coreos-ecordell laid out another option:

            Option 3: maybe it is possible to separate OLM stack the same way cluster- user-workload monitoring are

            Josh Gwosdz added a comment - rhn-coreos-ecordell laid out another option: Option 3: maybe it is possible to separate OLM stack the same way cluster- user-workload monitoring are

            Amador Pahim Segundo (Inactive) added a comment -

            Option 1: define dependencies by bundle digest

            Option 2: define dependencies that are trusted (signed bundles)

            Amador Pahim Segundo (Inactive) added a comment - Option 1: define dependencies by bundle digest Option 2: define dependencies that are trusted (signed bundles)

            Amador Pahim Segundo (Inactive) added a comment -

            amoran@redhat.com

            Amador Pahim Segundo (Inactive) added a comment - amoran@redhat.com

              Unassigned Unassigned
              rhn-support-apahim Amador Pahim Segundo (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: