mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
Add pkgman-to-bundle OSDK docs
This commit is contained in:
Alex Dellapenta
committed by
openshift-cherrypick-robot
openshift-cherrypick-robot
parent
dabf83f6f8
commit
2d569f0532
@@ -1271,6 +1271,8 @@ Topics:
|
||||
File: osdk-monitoring-prometheus
|
||||
- Name: Configuring leader election
|
||||
File: osdk-leader-election
|
||||
- Name: Migrating package manifest projects to bundle format
|
||||
File: osdk-pkgman-to-bundle
|
||||
- Name: Operator SDK CLI reference
|
||||
File: osdk-cli-ref
|
||||
- Name: Migrating to Operator SDK v0.1.0
|
||||
|
||||
@@ -8,7 +8,7 @@ toc::[]
|
||||
include::modules/olm-about-opm.adoc[leveloffset=+1]
|
||||
.Additional resources
|
||||
|
||||
* See xref:../operators/understanding/olm-packaging-format.adoc#olm-bundle-format_olm-packaging-format[Operator Framework packaging formats] for more information about the Bundle Format.
|
||||
* See xref:../operators/understanding/olm-packaging-format.adoc#olm-bundle-format_olm-packaging-format[Operator Framework packaging formats] for more information about the bundle format.
|
||||
* To create a bundle image using the Operator SDK, see
|
||||
xref:../operators/operator_sdk/osdk-working-bundle-images.adoc#osdk-working-bundle-images[Working with bundle images].
|
||||
|
||||
|
||||
@@ -7,11 +7,11 @@
|
||||
|
||||
An Operator catalog is a repository of metadata that Operator Lifecycle Manager (OLM) can query to discover and install Operators and their dependencies on a cluster. OLM always installs Operators from the latest version of a catalog. As of {product-title} 4.6, Red Hat-provided catalogs are distributed using _index images_.
|
||||
|
||||
An index image, based on the Operator Bundle Format, is a containerized snapshot of a catalog. It is an immutable artifact that contains the database of pointers to a set of Operator manifest content. A catalog can reference an index image to source its content for OLM on the cluster.
|
||||
An index image, based on the Operator bundle format, is a containerized snapshot of a catalog. It is an immutable artifact that contains the database of pointers to a set of Operator manifest content. A catalog can reference an index image to source its content for OLM on the cluster.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
Starting in {product-title} 4.6, index images provided by Red Hat replace the App Registry catalog images, based on the deprecated Package Manifest Format, that are distributed for previous versions of {product-title} 4. While App Registry catalog images are not distributed by Red Hat for {product-title} 4.6 and later, custom catalog images based on the Package Manifest Format are still supported.
|
||||
Starting in {product-title} 4.6, index images provided by Red Hat replace the App Registry catalog images, based on the deprecated package manifest format, that are distributed for previous versions of {product-title} 4. While App Registry catalog images are not distributed by Red Hat for {product-title} 4.6 and later, custom catalog images based on the package manifest format are still supported.
|
||||
====
|
||||
|
||||
As catalogs are updated, the latest versions of Operators change, and older versions may be removed or altered. In addition, when OLM runs on an {product-title} cluster in a restricted network environment, it is unable to access the catalogs directly from the Internet to pull the latest content.
|
||||
|
||||
@@ -6,6 +6,6 @@
|
||||
[id="olm-about-opm_{context}"]
|
||||
= About opm
|
||||
|
||||
The `opm` CLI tool is provided by the Operator Framework for use with the Operator Bundle Format. This tool allows you to create and maintain catalogs of Operators from a list of bundles, called an _index_, that are similar to software repositories. The result is a container image, called an _index image_, which can be stored in a container registry and then installed on a cluster.
|
||||
The `opm` CLI tool is provided by the Operator Framework for use with the Operator bundle format. This tool allows you to create and maintain catalogs of Operators from a list of bundles, called an _index_, that are similar to software repositories. The result is a container image, called an _index image_, which can be stored in a container registry and then installed on a cluster.
|
||||
|
||||
An index contains a database of pointers to Operator manifest content that can be queried through an included API that is served when the container image is run. On {product-title}, Operator Lifecycle Manager (OLM) can use the index image as a catalog by referencing it in a `CatalogSource` object, which polls the image at regular intervals to enable frequent updates to installed Operators on the cluster.
|
||||
|
||||
@@ -11,7 +11,7 @@ Other images required by an Operator or its Operands might require access to pri
|
||||
|
||||
The following types of images should be considered when determining whether Operators managed by OLM have appropriate pull access:
|
||||
|
||||
Index or catalog images:: A `CatalogSource` object can reference an index image or a catalog image, which are catalog sources packaged as container images hosted in images registries. Index images use the Bundle Format and reference bundle images, while catalog images use the Package Manifest Format. If an index or catalog image is hosted in a private registry, a secret can be used to enable pull access.
|
||||
Index or catalog images:: A `CatalogSource` object can reference an index image or a catalog image, which are catalog sources packaged as container images hosted in images registries. Index images use the bundle format and reference bundle images, while catalog images use the package manifest format. If an index or catalog image is hosted in a private registry, a secret can be used to enable pull access.
|
||||
|
||||
Bundle images:: Operator bundle images are metadata and manifests packaged as container images that represent a unique version of an Operator. If any bundle images referenced in a catalog source are hosted in one or more private registries, a secret can be used to enable pull access.
|
||||
|
||||
|
||||
@@ -10,9 +10,9 @@ ifndef::openshift-origin[]
|
||||
endif::[]
|
||||
|
||||
[id="olm-building-operator-catalog-image_{context}"]
|
||||
= Building a Package Manifest Format catalog image
|
||||
= Building a package manifest format catalog image
|
||||
|
||||
Cluster administrators can build a custom Operator catalog image based on the Package Manifest Format to be used by Operator Lifecycle Manager (OLM). The catalog image can be pushed to a container image registry that supports link:https://docs.docker.com/registry/spec/manifest-v2-2/[Docker v2-2]. For a cluster on a restricted network, this registry can be a registry that the cluster has network access to, such as a mirror registry created during a restricted network cluster installation.
|
||||
Cluster administrators can build a custom Operator catalog image based on the package manifest format to be used by Operator Lifecycle Manager (OLM). The catalog image can be pushed to a container image registry that supports link:https://docs.docker.com/registry/spec/manifest-v2-2/[Docker v2-2]. For a cluster on a restricted network, this registry can be a registry that the cluster has network access to, such as a mirror registry created during a restricted network cluster installation.
|
||||
|
||||
For this example, the procedure assumes use of a mirror registry that has access to both your network and the Internet.
|
||||
|
||||
|
||||
@@ -3,9 +3,9 @@
|
||||
// * operators/understanding/olm/olm-packaging-format.adoc
|
||||
|
||||
[id="olm-bundle-format_{context}"]
|
||||
= Bundle Format
|
||||
= Bundle format
|
||||
|
||||
The _Bundle Format_ for Operators is a new packaging format introduced by the Operator Framework. To improve scalability and to better enable upstream users hosting their own catalogs, the Bundle Format specification simplifies the distribution of Operator metadata.
|
||||
The _bundle format_ for Operators is a new packaging format introduced by the Operator Framework. To improve scalability and to better enable upstream users hosting their own catalogs, the bundle format specification simplifies the distribution of Operator metadata.
|
||||
|
||||
An Operator bundle represents a single version of an Operator. On-disk _bundle manifests_ are containerized and shipped as a _bundle image_, which is a non-runnable container image that stores the Kubernetes manifests and Operator metadata. Storage and distribution of the bundle image is then managed using existing container tools like `podman` and `docker` and container registries such as Quay.
|
||||
|
||||
@@ -29,7 +29,7 @@ Bundle manifests refer to a set of Kubernetes manifests that define the deployme
|
||||
|
||||
A bundle includes one CSV per directory and typically the CRDs that define the owned APIs of the CSV in its `/manifests` directory.
|
||||
|
||||
.Example Bundle Format layout
|
||||
.Example bundle format layout
|
||||
[source,terminal]
|
||||
----
|
||||
etcd
|
||||
|
||||
@@ -184,7 +184,7 @@ If your cluster uses an `ImageContentSourcePolicy` object to configure repositor
|
||||
+
|
||||
[IMPORTANT]
|
||||
====
|
||||
If you used the `--manifests-only` flag during the mirroring process and want to further trim the subset of packages to be mirrored, see the steps in the "Mirroring a Package Manifest Format catalog image" procedure about modifying your `mapping.txt` file and using the file with the `oc image mirror` command. After following those further actions, you can continue this procedure.
|
||||
If you used the `--manifests-only` flag during the mirroring process and want to further trim the subset of packages to be mirrored, see the steps in the "Mirroring a package manifest format catalog image" procedure about modifying your `mapping.txt` file and using the file with the `oc image mirror` command. After following those further actions, you can continue this procedure.
|
||||
====
|
||||
--
|
||||
|
||||
|
||||
@@ -3,14 +3,14 @@
|
||||
// * operators/admin/olm-managing-custom-catalogs.adoc
|
||||
|
||||
[id="olm-mirroring-package-manifest-catalog_{context}"]
|
||||
= Mirroring a Package Manifest Format catalog image
|
||||
= Mirroring a package manifest format catalog image
|
||||
|
||||
Cluster administrators can mirror a custom Operator catalog image based on the Package Manifest Format into a registry and use a catalog source to load the content onto their cluster. For this example, the procedure uses a custom `redhat-operators` catalog image previously built and pushed to a supported registry.
|
||||
Cluster administrators can mirror a custom Operator catalog image based on the package manifest format into a registry and use a catalog source to load the content onto their cluster. For this example, the procedure uses a custom `redhat-operators` catalog image previously built and pushed to a supported registry.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* Workstation with unrestricted network access
|
||||
* A custom Operator catalog image based on the Package Manifest Format pushed to a supported registry
|
||||
* A custom Operator catalog image based on the package manifest format pushed to a supported registry
|
||||
* `oc` version 4.3.5+
|
||||
* `podman` version 1.9.3+
|
||||
* Access to mirror registry that supports link:https://docs.docker.com/registry/spec/manifest-v2-2/[Docker v2-2]
|
||||
|
||||
@@ -3,13 +3,13 @@
|
||||
// * operators/admin/olm-managing-custom-catalogs.adoc
|
||||
|
||||
[id="olm-package-manifest-format-catalogsource_{context}"]
|
||||
= Creating a catalog from a Package Manifest Format catalog image
|
||||
= Creating a catalog from a package manifest format catalog image
|
||||
|
||||
Cluster administrators use a custom Operator catalog image based on the Package Manifest Format to create a catalog source that loads the Operator content onto their cluster. For this example, the procedure uses a custom `redhat-operators` catalog image previously built and pushed to a supported registry.
|
||||
Cluster administrators use a custom Operator catalog image based on the package manifest format to create a catalog source that loads the Operator content onto their cluster. For this example, the procedure uses a custom `redhat-operators` catalog image previously built and pushed to a supported registry.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* A custom Operator catalog image based on the Package Manifest Format pushed to a supported registry
|
||||
* A custom Operator catalog image based on the package manifest format pushed to a supported registry
|
||||
* `oc` version 4.3.5+
|
||||
|
||||
.Procedure
|
||||
|
||||
@@ -3,15 +3,20 @@
|
||||
// * operators/understanding/olm/olm-packaging-formats.adoc
|
||||
|
||||
[id="olm-package-manifest-format_{context}"]
|
||||
= Package Manifest Format
|
||||
= Package manifest format
|
||||
|
||||
The _Package Manifest Format_ for Operators is the legacy packaging format introduced by the Operator Framework. While this format is deprecated in {product-title} 4.5, it is still supported and Operators provided by Red Hat are currently shipped using this method.
|
||||
The _package manifest format_ for Operators is the legacy packaging format introduced by the Operator Framework. While this format is deprecated in {product-title} 4.5, it is still supported and Operators provided by Red Hat are currently shipped using this method.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
Existing Operator projects in the package manifest format can be migrated to the bundle format by using the Operator SDK `pkgman-to-bundle` command.
|
||||
====
|
||||
|
||||
In this format, a version of an Operator is represented by a single cluster service version (CSV) and typically the custom resource definitions (CRDs) that define the owned APIs of the CSV, though additional objects may be included.
|
||||
|
||||
All versions of the Operator are nested in a single directory:
|
||||
|
||||
.Example Package Manifest Format layout
|
||||
.Example package manifest format layout
|
||||
[source,terminal]
|
||||
----
|
||||
etcd
|
||||
|
||||
@@ -28,7 +28,7 @@ endif::[]
|
||||
[id="olm-pruning-index-image_{context}"]
|
||||
= Pruning an index image
|
||||
|
||||
An index image, based on the Operator Bundle Format, is a containerized snapshot of an Operator catalog. You can prune an index of all but a specified list of packages, which creates a copy of the source index containing only the Operators that you want.
|
||||
An index image, based on the Operator bundle format, is a containerized snapshot of an Operator catalog. You can prune an index of all but a specified list of packages, which creates a copy of the source index containing only the Operators that you want.
|
||||
|
||||
ifeval::["{context}" != "olm-managing-custom-catalogs"]
|
||||
When configuring Operator Lifecycle Manager (OLM) to use mirrored content on restricted network {product-title} clusters, use this pruning method if you want to only mirror a subset of Operators from the default catalogs.
|
||||
|
||||
@@ -7,11 +7,11 @@
|
||||
|
||||
[id="olm-common-terms-bundle_{context}"]
|
||||
== Bundle
|
||||
In the Bundle Format, a _bundle_ is a collection of an Operator CSV, manifests, and metadata. Together, they form a unique version of an Operator that can be installed onto the cluster.
|
||||
In the bundle format, a _bundle_ is a collection of an Operator CSV, manifests, and metadata. Together, they form a unique version of an Operator that can be installed onto the cluster.
|
||||
|
||||
[id="olm-common-terms-bundle-image_{context}"]
|
||||
== Bundle image
|
||||
In the Bundle Format, a _bundle image_ is a container image that is built from Operator manifests and that contains one bundle. Bundle images are stored and distributed by Open Container Initiative (OCI) spec container registries, such as Quay.io or DockerHub.
|
||||
In the bundle format, a _bundle image_ is a container image that is built from Operator manifests and that contains one bundle. Bundle images are stored and distributed by Open Container Initiative (OCI) spec container registries, such as Quay.io or DockerHub.
|
||||
|
||||
[id="olm-common-terms-catalogsource_{context}"]
|
||||
== Catalog source
|
||||
@@ -19,7 +19,7 @@ A _catalog source_ is a repository of CSVs, CRDs, and packages that define an ap
|
||||
|
||||
[id="olm-common-terms-catalog-image_{context}"]
|
||||
== Catalog image
|
||||
In the Package Manifest Format, a _catalog image_ is a containerized datastore that describes a set of Operator metadata and update metadata that can be installed onto a cluster using OLM.
|
||||
In the package manifest format, a _catalog image_ is a containerized datastore that describes a set of Operator metadata and update metadata that can be installed onto a cluster using OLM.
|
||||
|
||||
[id="olm-common-terms-channel_{context}"]
|
||||
== Channel
|
||||
@@ -48,7 +48,7 @@ OLM resolves dependencies by ensuring that all specified versions of Operators a
|
||||
|
||||
[id="olm-common-terms-index-image_{context}"]
|
||||
== Index image
|
||||
In the Bundle Format, an _index image_ refers to an image of a database (a database snapshot) that contains information about Operator bundles including CSVs and CRDs of all versions. This index can host a history of Operators on a cluster and be maintained by adding or removing Operators using the `opm` CLI tool.
|
||||
In the bundle format, an _index image_ refers to an image of a database (a database snapshot) that contains information about Operator bundles including CSVs and CRDs of all versions. This index can host a history of Operators on a cluster and be maintained by adding or removing Operators using the `opm` CLI tool.
|
||||
|
||||
[id="olm-common-terms-installplan_{context}"]
|
||||
== Install plan
|
||||
@@ -61,7 +61,7 @@ An _Operator group_ configures all Operators deployed in the same namespace as t
|
||||
|
||||
[id="olm-common-terms-package_{context}"]
|
||||
== Package
|
||||
In the Bundle Format, a _package_ is a directory that encloses all released history of an Operator with each version. A released version of an Operator is described in a CSV manifest alongside the CRDs.
|
||||
In the bundle format, a _package_ is a directory that encloses all released history of an Operator with each version. A released version of an Operator is described in a CSV manifest alongside the CRDs.
|
||||
|
||||
[id="olm-common-terms-registry_{context}"]
|
||||
== Registry
|
||||
|
||||
@@ -3,13 +3,13 @@
|
||||
// * operators/admin/olm-managing-custom-catalogs.adoc
|
||||
|
||||
[id="olm-testing-operator-catalog-image_{context}"]
|
||||
= Testing a Package Manifest Format catalog image
|
||||
= Testing a package manifest format catalog image
|
||||
|
||||
You can validate Operator catalog image content by running it as a container and querying its gRPC API. To further test the image, you can then resolve a subscription in Operator Lifecycle Manager (OLM) by referencing the image in a catalog source. For this example, the procedure uses a custom `redhat-operators` catalog image previously built and pushed to a supported registry.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* A custom Package Manifest Format catalog image pushed to a supported registry
|
||||
* A custom package manifest format catalog image pushed to a supported registry
|
||||
* `podman` version 1.9.3+
|
||||
* `oc` version 4.3.5+
|
||||
* Access to mirror registry that supports link:https://docs.docker.com/registry/spec/manifest-v2-2/[Docker v2-2]
|
||||
|
||||
@@ -10,7 +10,7 @@ ifndef::openshift-origin[]
|
||||
endif::[]
|
||||
|
||||
[id="olm-updating-operator-catalog-image_{context}"]
|
||||
= Updating a Package Manifest Format catalog image
|
||||
= Updating a package manifest format catalog image
|
||||
|
||||
After a cluster administrator has configured OperatorHub to use custom Operator catalog images, administrators can keep their {product-title} cluster up to date with the latest Operators by capturing updates made to App Registry catalogs provided by Red Hat. This is done by building and pushing a new Operator catalog image, then replacing the existing `spec.image` parameter in the `CatalogSource` object with the new image digest.
|
||||
|
||||
|
||||
61
modules/osdk-about-pkg-format-migration.adoc
Normal file
61
modules/osdk-about-pkg-format-migration.adoc
Normal file
@@ -0,0 +1,61 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * operators/operator_sdk/osdk-pkgman-to-bundle.adoc
|
||||
|
||||
[id="osdk-about-pkg-format-migration_{context}"]
|
||||
= About packaging format migration
|
||||
|
||||
The Operator SDK `pkgman-to-bundle` command helps in migrating Operator Lifecycle Manager (OLM) package manifests to bundles. The command takes an input package manifest directory and generates bundles for each of the versions of manifests present in the input directory. You can also then build bundle images for each of the generated bundles.
|
||||
|
||||
For example, consider the following `packagemanifests/` directory for a project in the package manifest format:
|
||||
|
||||
.Example package manifest format layout
|
||||
[source,terminal]
|
||||
----
|
||||
packagemanifests/
|
||||
└── etcd
|
||||
├── 0.0.1
|
||||
│ ├── etcdcluster.crd.yaml
|
||||
│ └── etcdoperator.clusterserviceversion.yaml
|
||||
├── 0.0.2
|
||||
│ ├── etcdbackup.crd.yaml
|
||||
│ ├── etcdcluster.crd.yaml
|
||||
│ ├── etcdoperator.v0.0.2.clusterserviceversion.yaml
|
||||
│ └── etcdrestore.crd.yaml
|
||||
└── etcd.package.yaml
|
||||
----
|
||||
|
||||
After running the migration, the following bundles are generated in the `bundle/` directory:
|
||||
|
||||
.Example bundle format layout
|
||||
[source,terminal]
|
||||
----
|
||||
bundle/
|
||||
├── bundle-0.0.1
|
||||
│ ├── bundle.Dockerfile
|
||||
│ ├── manifests
|
||||
│ │ ├── etcdcluster.crd.yaml
|
||||
│ │ ├── etcdoperator.clusterserviceversion.yaml
|
||||
│ ├── metadata
|
||||
│ │ └── annotations.yaml
|
||||
│ └── tests
|
||||
│ └── scorecard
|
||||
│ └── config.yaml
|
||||
└── bundle-0.0.2
|
||||
├── bundle.Dockerfile
|
||||
├── manifests
|
||||
│ ├── etcdbackup.crd.yaml
|
||||
│ ├── etcdcluster.crd.yaml
|
||||
│ ├── etcdoperator.v0.0.2.clusterserviceversion.yaml
|
||||
│ ├── etcdrestore.crd.yaml
|
||||
├── metadata
|
||||
│ └── annotations.yaml
|
||||
└── tests
|
||||
└── scorecard
|
||||
└── config.yaml
|
||||
----
|
||||
|
||||
Based on this generated layout, bundle images for both of the bundles are also built with the following names:
|
||||
|
||||
* `quay.io/example/etcd:0.0.1`
|
||||
* `quay.io/example/etcd:0.0.2`
|
||||
@@ -17,7 +17,7 @@ endif::[]
|
||||
|
||||
Operator Lifecycle Manager (OLM) helps you to install, update, and generally manage the lifecycle of Operators and their associated services on a Kubernetes cluster. OLM is installed by default on {product-title} and runs as a Kubernetes extension so that you can use the web console and the OpenShift CLI (`oc`) for all Operator lifecycle management functions without any additional tools.
|
||||
|
||||
The Operator Bundle Format is the default packaging method for Operator SDK and OLM. You can get your Operator ready for OLM by using the Operator SDK to build, push, validate, and run a bundle image with OLM.
|
||||
The Operator bundle format is the default packaging method for Operator SDK and OLM. You can get your Operator ready for OLM by using the Operator SDK to build, push, validate, and run a bundle image with OLM.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
|
||||
60
modules/osdk-migrating-pkgman.adoc
Normal file
60
modules/osdk-migrating-pkgman.adoc
Normal file
@@ -0,0 +1,60 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * operators/operator_sdk/osdk-pkgman-to-bundle.adoc
|
||||
|
||||
[id="osdk-migrating-pkgman_{context}"]
|
||||
= Migrating a package manifest project to bundle format
|
||||
|
||||
Operator authors can use the Operator SDK to migrate a package manifest format Operator project to a bundle format project.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* Operator SDK CLI installed
|
||||
* Operator project initially generated using the Operator SDK in package manifest format
|
||||
|
||||
.Procedure
|
||||
|
||||
* Use the Operator SDK to migrate your package manifest project to the bundle format and generate bundle images:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ operator-sdk pkgman-to-bundle <package_manifests_dir> \ <1>
|
||||
[--output-dir <directory>] \ <2>
|
||||
--image-tag-base <image_name_base> <3>
|
||||
----
|
||||
<1> Specify the location of the package manifests directory for the project, such as `packagemanifests/` or `manifests/`.
|
||||
<2> Optional: By default, the generated bundles are written locally to disk to the `bundle/` directory. You can use the `--output-dir` flag to specify an alternative location.
|
||||
<3> Set the `--image-tag-base` flag to provide the base of the image name, such as `quay.io/example/etcd`, that will be used for the bundles. Provide the name without a tag, because the tag for the images will be set according to the bundle version. For example, the full bundle image names are generated in the format `<image_name_base>:<bundle_version>`.
|
||||
|
||||
////
|
||||
Reinsert in place after https://bugzilla.redhat.com/show_bug.cgi?id=1967369 is fixed:
|
||||
|
||||
[--build-cmd <command>] \ <3>
|
||||
|
||||
<3> Optional: Specify the build command for building container images using the `--build-cmd` flag. The default build command is `docker build`. The command must be in your `PATH`, otherwise you must provide a fully qualified path name.
|
||||
////
|
||||
|
||||
.Verification
|
||||
|
||||
* Verify that the generated bundle image runs successfully:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ operator-sdk run bundle <bundle_image_name>:<tag>
|
||||
----
|
||||
+
|
||||
.Example output
|
||||
[source,terminal]
|
||||
----
|
||||
INFO[0025] Successfully created registry pod: quay-io-my-etcd-0-9-4
|
||||
INFO[0025] Created CatalogSource: etcd-catalog
|
||||
INFO[0026] OperatorGroup "operator-sdk-og" created
|
||||
INFO[0026] Created Subscription: etcdoperator-v0-9-4-sub
|
||||
INFO[0031] Approved InstallPlan install-5t58z for the Subscription: etcdoperator-v0-9-4-sub
|
||||
INFO[0031] Waiting for ClusterServiceVersion "default/etcdoperator.v0.9.4" to reach 'Succeeded' phase
|
||||
INFO[0032] Waiting for ClusterServiceVersion "default/etcdoperator.v0.9.4" to appear
|
||||
INFO[0048] Found ClusterServiceVersion "default/etcdoperator.v0.9.4" phase: Pending
|
||||
INFO[0049] Found ClusterServiceVersion "default/etcdoperator.v0.9.4" phase: Installing
|
||||
INFO[0064] Found ClusterServiceVersion "default/etcdoperator.v0.9.4" phase: Succeeded
|
||||
INFO[0065] OLM has successfully installed "etcdoperator.v0.9.4"
|
||||
----
|
||||
@@ -5,14 +5,14 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
This guide describes how to work with custom catalogs for Operators packaged using either the xref:../../operators/understanding/olm-packaging-format.adoc#olm-bundle-format_olm-packaging-format[Bundle Format] or the legacy xref:../../operators/understanding/olm-packaging-format.adoc#olm-package-manifest-format_olm-packaging-format[Package Manifest Format] on Operator Lifecycle Manager (OLM) in {product-title}.
|
||||
This guide describes how to work with custom catalogs for Operators packaged using either the xref:../../operators/understanding/olm-packaging-format.adoc#olm-bundle-format_olm-packaging-format[bundle format] or the legacy xref:../../operators/understanding/olm-packaging-format.adoc#olm-package-manifest-format_olm-packaging-format[package manifest format] on Operator Lifecycle Manager (OLM) in {product-title}.
|
||||
|
||||
.Additional resources
|
||||
|
||||
* xref:../../operators/understanding/olm-rh-catalogs.adoc#olm-rh-catalogs[Red Hat-provided Operator catalogs]
|
||||
|
||||
[id="olm-managing-custom-catalogs-bundle-format"]
|
||||
== Custom catalogs using the Bundle Format
|
||||
== Custom catalogs using the bundle format
|
||||
|
||||
[id="olm-managing-custom-catalogs-bundle-format-prereqs"]
|
||||
=== Prerequisites
|
||||
@@ -29,7 +29,7 @@ include::modules/olm-updating-index-image.adoc[leveloffset=+2]
|
||||
include::modules/olm-pruning-index-image.adoc[leveloffset=+2]
|
||||
|
||||
[id="olm-managing-custom-catalogs-package-manifest-format"]
|
||||
== Custom catalogs using the Package Manifest Format
|
||||
== Custom catalogs using the package manifest format
|
||||
|
||||
include::modules/olm-building-operator-catalog-image.adoc[leveloffset=+2]
|
||||
.Additional resources
|
||||
|
||||
@@ -54,7 +54,7 @@ include::modules/olm-mirroring-catalog.adoc[leveloffset=+1]
|
||||
|
||||
* xref:../../installing/installing-mirroring-installation-images.adoc#installing-mirroring-installation-images[Mirroring images for a disconnected installation]
|
||||
* xref:../../operators/operator_sdk/osdk-generating-csvs.adoc#olm-arch-os-support_osdk-generating-csvs[Architecture and operating system support for Operators]
|
||||
* xref:../../operators/admin/olm-managing-custom-catalogs.adoc#olm-mirroring-package-manifest-catalog_olm-managing-custom-catalogs[Mirroring a Package Manifest Format catalog image]
|
||||
* xref:../../operators/admin/olm-managing-custom-catalogs.adoc#olm-mirroring-package-manifest-catalog_olm-managing-custom-catalogs[Mirroring a package manifest format catalog image]
|
||||
|
||||
include::modules/olm-creating-catalog-from-index.adoc[leveloffset=+1]
|
||||
* If your index image is hosted on a private registry and requires authentication, see xref:../../operators/admin/olm-managing-custom-catalogs.adoc#olm-accessing-images-private-registries_olm-managing-custom-catalogs[Accessing images for Operators from private registries].
|
||||
|
||||
14
operators/operator_sdk/osdk-pkgman-to-bundle.adoc
Normal file
14
operators/operator_sdk/osdk-pkgman-to-bundle.adoc
Normal file
@@ -0,0 +1,14 @@
|
||||
[id="osdk-pkgman-to-bundle"]
|
||||
= Migrating package manifest projects to bundle format
|
||||
include::modules/common-attributes.adoc[]
|
||||
:context: osdk-pkgman-to-bundle
|
||||
|
||||
toc::[]
|
||||
|
||||
If you have an Operator project that was initially created using the package manifest format, which is deprecated, you can use the Operator SDK to migrate the project to the bundle format. The bundle format is the preferred packaging format for Operator Lifecycle Manager (OLM) starting in {product-title} 4.6.
|
||||
|
||||
include::modules/osdk-about-pkg-format-migration.adoc[leveloffset=+1]
|
||||
.Additional resources
|
||||
* xref:../../operators/understanding/olm-packaging-format.adoc#olm-packaging-format[Operator Framework packaging formats]
|
||||
|
||||
include::modules/osdk-migrating-pkgman.adoc[leveloffset=+1]
|
||||
@@ -5,7 +5,7 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
You can use the Operator SDK to package, deploy, and upgrade Operators in the Bundle Format on Operator Lifecycle Manager (OLM).
|
||||
You can use the Operator SDK to package, deploy, and upgrade Operators in the bundle format on Operator Lifecycle Manager (OLM).
|
||||
|
||||
include::modules/osdk-bundle-deploy-olm.adoc[leveloffset=+1]
|
||||
include::modules/osdk-bundle-upgrade-olm.adoc[leveloffset=+1]
|
||||
@@ -13,6 +13,6 @@ include::modules/osdk-bundle-upgrade-olm.adoc[leveloffset=+1]
|
||||
[id="osdk-working-bundle-images-additional-resources"]
|
||||
== Additional resources
|
||||
|
||||
* See xref:../../operators/understanding/olm-packaging-format.adoc#olm-bundle-format_olm-packaging-format[Operator Framework packaging formats] for details on the Bundle Format.
|
||||
* See xref:../../operators/understanding/olm-packaging-format.adoc#olm-bundle-format_olm-packaging-format[Operator Framework packaging formats] for details on the bundle format.
|
||||
* See xref:../../operators/admin/olm-managing-custom-catalogs.adoc#olm-managing-custom-catalogs[Managing custom catalogs] for details on adding bundle images to index images by using the `opm` command.
|
||||
* See xref:../../operators/understanding/olm/olm-workflow.adoc#olm-workflow[Operator Lifecycle Manager workflow] for details on how upgrades work for installed Operators.
|
||||
|
||||
@@ -5,6 +5,6 @@ include::modules/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
This topic provides a glossary of common terms related to the Operator Framework, including Operator Lifecycle Manager (OLM) and the Operator SDK, for both packaging formats: Package Manifest Format and Bundle Format.
|
||||
This topic provides a glossary of common terms related to the Operator Framework, including Operator Lifecycle Manager (OLM) and the Operator SDK, for both packaging formats: package manifest format and bundle format.
|
||||
|
||||
include::modules/olm-terms.adoc[leveloffset=+1]
|
||||
|
||||
@@ -17,12 +17,14 @@ include::modules/olm-about-opm.adoc[leveloffset=+2]
|
||||
* See xref:../../cli_reference/opm-cli.adoc#opm-cli[CLI tools] for steps on installing the `opm` CLI.
|
||||
|
||||
include::modules/olm-package-manifest-format.adoc[leveloffset=+1]
|
||||
.Additional resources
|
||||
* xref:../../operators/operator_sdk/osdk-pkgman-to-bundle.adoc#osdk-pkgman-to-bundle[Migrating package manifest projects to bundle format]
|
||||
|
||||
ifdef::openshift-origin[]
|
||||
[id="olm-packaging-format-addtl-resources"]
|
||||
== Additional resources
|
||||
|
||||
See the upstream `operator-framework/operator-registry` project repository for more information on the Operator Bundle Format:
|
||||
See the upstream `operator-framework/operator-registry` project repository for more information on the Operator bundle format:
|
||||
|
||||
- link:https://github.com/operator-framework/operator-registry/blob/master/docs/design/operator-bundle.md[Operator Bundle Overview]
|
||||
- link:https://github.com/operator-framework/operator-registry/blob/master/README.md[Operator Registry README]
|
||||
|
||||
Reference in New Issue
Block a user