|
| 1 | +// Module included in the following assemblies: |
| 2 | +// |
| 3 | +// * operators/admin/olm-managing-custom-catalogs.adoc |
| 4 | + |
| 5 | +ifdef::openshift-origin[] |
| 6 | +:registry-image: quay.io/operator-framework/opm:latest |
| 7 | +endif::[] |
| 8 | +ifndef::openshift-origin[] |
| 9 | +:registry-image: registry.redhat.io/openshift4/ose-operator-registry:v{product-version} |
| 10 | +endif::[] |
| 11 | + |
| 12 | +:_content-type: PROCEDURE |
| 13 | +[id="olm-filtering-fbc_{context}"] |
| 14 | += Filtering a file-based catalog image |
| 15 | + |
| 16 | +You can use the `opm` CLI to filter, or prune, a catalog image that uses the file-based catalog format. By extracting and updating the contents of an existing catalog image, you can remove one or more Operator packages from the catalog, and then rebuild the image as an updated version. |
| 17 | + |
| 18 | +[NOTE] |
| 19 | +==== |
| 20 | +Alternatively, if you already have a catalog image on a mirror registry, you can use the oc-mirror CLI plugin to automatically prune any removed images from an updated source version of that catalog image while mirroring it to the target registry. |
| 21 | +
|
| 22 | +For more information about the oc-mirror plugin and this use case, see the "Keeping your mirror registry content updated" section, and specifically the "Pruning images" subsection, of "Mirroring images for a disconnected installation using the oc-mirror plugin". |
| 23 | +==== |
| 24 | + |
| 25 | +.Prerequisites |
| 26 | + |
| 27 | +* `opm` CLI. |
| 28 | +* `podman` version 1.9.3+. |
| 29 | +* A file-based catalog image. |
| 30 | +* A catalog directory structure recently initialized on your workstation related to this catalog. |
| 31 | ++ |
| 32 | +If you do not have an initialized catalog directory, create the directory and generate the Dockerfile. For more information, see the "Initialize the catalog" step from the "Creating a file-based catalog image" procedure. |
| 33 | +
|
| 34 | +.Procedure |
| 35 | + |
| 36 | +. Extract the contents of the catalog image in YAML format to an `index.yaml` file in your catalog directory: |
| 37 | ++ |
| 38 | +[source,terminal] |
| 39 | +---- |
| 40 | +$ opm render <registry>/<namespace>/<catalog_image_name>:<tag> \ |
| 41 | + -o yaml > <catalog_dir>/index.yaml |
| 42 | +---- |
| 43 | ++ |
| 44 | +[NOTE] |
| 45 | +==== |
| 46 | +Alternatively, you can use the `-o json` flag to output in JSON format. |
| 47 | +==== |
| 48 | + |
| 49 | +. Modify the contents of the resulting `index.yaml` file to remove one or more Operator packages. |
| 50 | ++ |
| 51 | +[IMPORTANT] |
| 52 | +==== |
| 53 | +After a bundle has been published in a catalog, assume that one of your users has installed it. Ensure that all previously published bundles in a catalog have an update path to the current or newer channel head to avoid stranding users that have that version installed. |
| 54 | +==== |
| 55 | ++ |
| 56 | +The following example lists a set of `olm.package`, `olm.channel`, and `olm.bundle` blobs which must be deleted to remove an Operator package from the catalog: |
| 57 | ++ |
| 58 | +.Example removed entries |
| 59 | +[%collapsible] |
| 60 | +==== |
| 61 | +[source,yaml] |
| 62 | +---- |
| 63 | +--- |
| 64 | +defaultChannel: release-2.7 |
| 65 | +icon: |
| 66 | + base64data: <base64_string> |
| 67 | + mediatype: image/svg+xml |
| 68 | +name: example-operator |
| 69 | +schema: olm.package |
| 70 | +--- |
| 71 | +entries: |
| 72 | +- name: example-operator.v2.7.0 |
| 73 | + skipRange: '>=2.6.0 <2.7.0' |
| 74 | +- name: example-operator.v2.7.1 |
| 75 | + replaces: example-operator.v2.7.0 |
| 76 | + skipRange: '>=2.6.0 <2.7.1' |
| 77 | +- name: example-operator.v2.7.2 |
| 78 | + replaces: example-operator.v2.7.1 |
| 79 | + skipRange: '>=2.6.0 <2.7.2' |
| 80 | +- name: example-operator.v2.7.3 |
| 81 | + replaces: example-operator.v2.7.2 |
| 82 | + skipRange: '>=2.6.0 <2.7.3' |
| 83 | +- name: example-operator.v2.7.4 |
| 84 | + replaces: example-operator.v2.7.3 |
| 85 | + skipRange: '>=2.6.0 <2.7.4' |
| 86 | +name: release-2.7 |
| 87 | +package: example-operator |
| 88 | +schema: olm.channel |
| 89 | +--- |
| 90 | +image: example.com/example-inc/example-operator-bundle@sha256:<digest> |
| 91 | +name: example-operator.v2.7.0 |
| 92 | +package: example-operator |
| 93 | +properties: |
| 94 | +- type: olm.gvk |
| 95 | + value: |
| 96 | + group: example-group.example.io |
| 97 | + kind: MyObject |
| 98 | + version: v1alpha1 |
| 99 | +- type: olm.gvk |
| 100 | + value: |
| 101 | + group: example-group.example.io |
| 102 | + kind: MyOtherObject |
| 103 | + version: v1beta1 |
| 104 | +- type: olm.package |
| 105 | + value: |
| 106 | + packageName: example-operator |
| 107 | + version: 2.7.0 |
| 108 | +- type: olm.bundle.object |
| 109 | + value: |
| 110 | + data: <base64_string> |
| 111 | +- type: olm.bundle.object |
| 112 | + value: |
| 113 | + data: <base64_string> |
| 114 | +relatedImages: |
| 115 | +- image: example.com/example-inc/example-related-image@sha256:<digest> |
| 116 | + name: example-related-image |
| 117 | +schema: olm.bundle |
| 118 | +--- |
| 119 | +---- |
| 120 | +==== |
| 121 | +
|
| 122 | +. Save your changes to the `index.yaml` file. |
| 123 | +
|
| 124 | +. Validate the catalog: |
| 125 | ++ |
| 126 | +[source,terminal] |
| 127 | +---- |
| 128 | +$ opm validate <catalog_dir> |
| 129 | +---- |
| 130 | +
|
| 131 | +. Rebuild the catalog: |
| 132 | ++ |
| 133 | +[source,terminal] |
| 134 | +---- |
| 135 | +$ podman build . \ |
| 136 | + -f <catalog_dir>.Dockerfile \ |
| 137 | + -t <registry>/<namespace>/<catalog_image_name>:<tag> |
| 138 | +---- |
| 139 | +
|
| 140 | +. Push the updated catalog image to a registry: |
| 141 | ++ |
| 142 | +[source,terminal] |
| 143 | +---- |
| 144 | +$ podman push <registry>/<namespace>/<catalog_image_name>:<tag> |
| 145 | +---- |
| 146 | +
|
| 147 | +.Verification |
| 148 | +
|
| 149 | +. In the web console, navigate to the OperatorHub configuration resource in the *Administration* -> *Cluster Settings* -> *Configuration* page. |
| 150 | +
|
| 151 | +. Add the catalog source or update the existing catalog source to use the pull spec for your updated catalog image. |
| 152 | ++ |
| 153 | +For more information, see "Adding a catalog source to a cluster" in the "Additional resources" of this section. |
| 154 | +
|
| 155 | +. After the catalog source is in a *READY* state, navigate to the *Operators* -> *OperatorHub* page and check that the Operator package that you removed no longer appears. |
0 commit comments