Updated Operator catalog for oc-mirror

Author: subhtk

modules/oc-mirror-operator-catalog-filtering.adoc

@@ -10,10 +10,6 @@ oc-mirror plugin v2 selects the list of bundles for mirroring by processing the
 
 When oc-mirror plugin v2 selects bundles for mirroring, it does not infer Group Version Kind (GVK) or bundle dependencies, omitting them from the mirroring set. Instead, it strictly adheres to the user instructions. You must explicitly specify any required dependent packages and their versions.
 
-Bundle versions typically use semantic versioning standards (SemVer), and you can sort bundles within a channel by version. You can select buncles that fall within a specific range in the `ImageSetConfig`.
-
-This selection algorithm ensures consistent outcomes compared to oc-mirror plugin v1. However, it does not include upgrade graph details, such as `replaces`, `skip`, and `skipRange`. This approach differs from the OLM algorithm. It might mirror more bundles than necessary for upgrading a cluster because of potentially shorter upgrade paths between the `minVersion` and `maxVersion`.
-
 .Use the following table to see what bundle versions are included in different scenarios
 [cols="1,2",options="header"]
 
@@ -31,7 +27,7 @@ mirror:
  operators:
    - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.10
 ----
-|For each package in the catalog, 1 bundle, corresponding to the head version of the default channel for that package.
+|For each package in the catalog, one bundle, corresponding to the head version for each channel of that package.
 
 a|Scenario 2
 
@@ -42,7 +38,7 @@ mirror:
     - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.10
       full: true
 ----
-|All bundles of all channels of the specified catalog
+|All bundles of all channels of the specified catalog.
 
 a|Scenario 3
 
@@ -54,7 +50,7 @@ mirror:
      packages: 
     - name: compliance-operator
 ----
-|One bundle, corresponding to the head version of the default channel for that package
+|One bundle, corresponding to the head version for each channel of that package.
 
 a|Scenario 4
 
@@ -67,7 +63,7 @@ mirror:
       - packages:
           - name: elasticsearch-operator
 ----
-|All bundles of all channels for the packages specified
+|All bundles of all channels for the packages specified.
 
 a|Scenario 5
 
@@ -80,7 +76,7 @@ mirror:
     - name: compliance-operator
        minVersion: 5.6.0
 ----
-|All bundles in the default channel, from the `minVersion`, up to the channel head for that package that do not rely on the shortest path from upgrade the graph.
+|All bundles in all channels, from the `minVersion`, up to the channel head for that package.
 
 a|Scenario 6
 
@@ -93,7 +89,7 @@ mirror:
     - name: compliance-operator
         maxVersion: 6.0.0
 ----
-|All bundles in the default channel that are lower than the `maxVersion` for that package.
+|All bundles in all channels that are lower than the `maxVersion` for that package.
 
 a|Scenario 7
 
@@ -107,7 +103,7 @@ mirror:
         minVersion: 5.6.0
         maxVersion: 6.0.0
 ----
-|All bundles in the default channel, between the `minVersion` and `maxVersion` for that package. The head of the channel is not included, even if multiple channels are included in the filtering.
+|All bundles in all channels, between the `minVersion` and `maxVersion` for that package. The head of the channel is not included, even if multiple channels are included in the filtering.
 
 a|Scenario 8
 
@@ -121,7 +117,7 @@ mirror:
         channels
           - name: stable
 ----
-|The head bundle for the selected channel of that package.
+|The head bundle for the selected channel of that package. You must use the `defaultChannel` field in case the filtered channels are not the default.
 
 a|Scenario 9
 
@@ -136,7 +132,8 @@ mirror:
             channels:
                - name: 'stable-v0'
 ----
-|All bundles for the specified packages and channels.
+|All bundles for the packages and channels specified.
+The `defaultChannel` should be used in case the filtered channels are not the default.
 
 a|Scenario 10
 
@@ -166,7 +163,7 @@ mirror:
           - name: stable
             minVersion: 5.6.0
 ----
-|Within the selected channel of that package, all versions starting with the `minVersion` up to the channel head. This scenario does not relyon the shortest path from the upgrade graph.
+|Within the selected channel of that package, all versions starting with the `minVersion` up to the channel head. You must use the `defaultChannel` field in case the filtered channels are not the default.
 
 a|Scenario 12
 
@@ -181,7 +178,9 @@ mirror:
           - name: stable
             maxVersion: 6.0.0
 ----
-|Within the selected channel of that package, all versions up to the `maxVersion` (not relying on the shortest path from the upgrade graph). The head of the channel is not included, even if multiple channels are included in the filtering.
+|Within the selected channel of that package, all versions up to `maxVersion`.
+Head of channel is not included, even if multiple channels are included in the filtering.
+You might see errors if this filtering leads to a channel with multiple heads. You must use the `defaultChannel` field in case the filtered channels are not the default.
 
 a|Scenario 13
 
@@ -197,7 +196,8 @@ mirror:
             minVersion: 5.6.0
             maxVersion: 6.0.0
 ----
-|Within the selected channel of that package, all versions between the `minVersion` and `maxVersion`, not relying on the shortest path from the upgrade graph. The head of the channel is not included, even if multiple channels are included in the filtering.
+|Within the selected channel of that package, all versions between the `minVersion` and `maxVersion`. The head of channel is not included, even if multiple channels are included in the filtering.
+You might see errors if this filtering leads to a channel with multiple heads. You must use the `defaultChannel` field in case the filtered channels are not the default.
 
 a|Scenario 14