diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml index 38722f80f8..c777e659f9 100644 --- a/_topic_maps/_topic_map.yml +++ b/_topic_maps/_topic_map.yml @@ -1994,8 +1994,6 @@ Topics: File: olmv1-catalogd - Name: Installing an Operator from a catalog File: olmv1-installing-an-operator-from-a-catalog - - Name: Managing plain bundles - File: olmv1-managing-plain-bundles --- Name: CI/CD Dir: cicd diff --git a/modules/olm-rukpak-plain-bundle.adoc b/_unused_topics/olm-rukpak-plain-bundle.adoc similarity index 99% rename from modules/olm-rukpak-plain-bundle.adoc rename to _unused_topics/olm-rukpak-plain-bundle.adoc index 6b36cc4b31..50b4c5eef8 100644 --- a/modules/olm-rukpak-plain-bundle.adoc +++ b/_unused_topics/olm-rukpak-plain-bundle.adoc @@ -35,4 +35,4 @@ The static manifests must be located in the `manifests/` directory with at least [IMPORTANT] ==== Do not include any content in the `manifests/` directory of a plain bundle that are not static manifests. Otherwise, a failure will occur when creating content on-cluster from that bundle. Any file that would not successfully apply with the `oc apply` command will result in an error. Multi-object YAML or JSON files are valid, as well. -==== \ No newline at end of file +==== diff --git a/modules/olmv1-adding-plain-to-fbc.adoc b/_unused_topics/olmv1-adding-plain-to-fbc.adoc similarity index 99% rename from modules/olmv1-adding-plain-to-fbc.adoc rename to _unused_topics/olmv1-adding-plain-to-fbc.adoc index 705aba85e4..1bfa33f03a 100644 --- a/modules/olmv1-adding-plain-to-fbc.adoc +++ b/_unused_topics/olmv1-adding-plain-to-fbc.adoc @@ -118,4 +118,4 @@ The `opm render` command does not support adding plain bundles to catalogs. You [source,terminal] ---- $ opm validate ----- \ No newline at end of file +---- diff --git a/modules/olmv1-building-plain-image.adoc b/_unused_topics/olmv1-building-plain-image.adoc similarity index 99% rename from modules/olmv1-building-plain-image.adoc rename to _unused_topics/olmv1-building-plain-image.adoc index 5f2bd160f4..e1e7e40a4e 100644 --- a/modules/olmv1-building-plain-image.adoc +++ b/_unused_topics/olmv1-building-plain-image.adoc @@ -35,4 +35,4 @@ $ podman build -f plainbundle.Dockerfile -t \ [source,terminal] ---- $ podman push quay.io//: ----- \ No newline at end of file +---- diff --git a/operators/olm_v1/olmv1-managing-plain-bundles.adoc b/_unused_topics/olmv1-managing-plain-bundles.adoc similarity index 97% rename from operators/olm_v1/olmv1-managing-plain-bundles.adoc rename to _unused_topics/olmv1-managing-plain-bundles.adoc index 55db28763d..7a90a66e46 100644 --- a/operators/olm_v1/olmv1-managing-plain-bundles.adoc +++ b/_unused_topics/olmv1-managing-plain-bundles.adoc @@ -69,4 +69,4 @@ manifests include::modules/olmv1-building-plain-image.adoc[leveloffset=+1] include::modules/olmv1-creating-fbc.adoc[leveloffset=+1] include::modules/olmv1-adding-plain-to-fbc.adoc[leveloffset=+1] -include::modules/olmv1-publishing-fbc.adoc[leveloffset=+1] \ No newline at end of file +include::modules/olmv1-publishing-fbc.adoc[leveloffset=+1] diff --git a/modules/arch-platform-operators.adoc b/modules/arch-platform-operators.adoc deleted file mode 100644 index abe61345e8..0000000000 --- a/modules/arch-platform-operators.adoc +++ /dev/null @@ -1,25 +0,0 @@ -// Module included in the following assemblies: -// -// * architecture/control-plane.adoc -// * operators/admin/olm-managing-po.adoc - -:_mod-docs-content-type: CONCEPT - -ifeval::["{context}" == "control-plane"] -[id="platform-operators_{context}"] -= Platform Operators (Technology Preview) - -:FeatureName: The platform Operator type -include::snippets/technology-preview.adoc[] -endif::[] - -ifeval::["{context}" == "olm-managing-po"] -[id="platform-operators_{context}"] -= About platform Operators -endif::[] - -Operator Lifecycle Manager (OLM) introduces a new type of Operator called _platform Operators_. A platform Operator is an OLM-based Operator that can be installed during or after an {product-title} cluster's Day 0 operations and participates in the cluster's lifecycle. As a cluster administrator, you can use platform Operators to further customize your {product-title} installation to meet your requirements and use cases. - -Using the existing cluster capabilities feature in {product-title}, cluster administrators can already disable a subset of Cluster Version Operator-based (CVO) components considered non-essential to the initial payload prior to cluster installation. Platform Operators iterate on this model by providing additional customization options. Through the platform Operator mechanism, which relies on resources from the RukPak component, OLM-based Operators can now be installed at cluster installation time and can block cluster rollout if the Operator fails to install successfully. - -In {product-title} 4.12, this Technology Preview release focuses on the basic platform Operator mechanism and builds a foundation for expanding the concept in upcoming releases. You can use the cluster-wide `PlatformOperator` API to configure Operators before or after cluster creation on clusters that have enabled the `TechPreviewNoUpgrade` feature set. \ No newline at end of file diff --git a/modules/olm-rukpak-bd.adoc b/modules/olm-rukpak-bd.adoc index e145663da9..c98f9e7628 100644 --- a/modules/olm-rukpak-bd.adoc +++ b/modules/olm-rukpak-bd.adoc @@ -16,24 +16,3 @@ The RukPak `BundleDeployment` API points to a `Bundle` object and indicates that Much like pods generate instances of container images, a bundle deployment generates a deployed version of a bundle. A bundle deployment can be seen as a generalization of the pod concept. The specifics of how a bundle deployment makes changes to a cluster based on a referenced bundle is defined by the provisioner that is configured to watch that bundle deployment. - -.Example `BundleDeployment` object configured to work with the plain provisioner -[source,yaml] ----- -apiVersion: core.rukpak.io/v1alpha1 -kind: BundleDeployment -metadata: - name: my-bundle-deployment -spec: - provisionerClassName: core-rukpak-io-plain - template: - metadata: - labels: - app: my-bundle - spec: - source: - type: image - image: - ref: my-bundle@sha256:xyz123 - provisionerClassName: core-rukpak-io-plain ----- \ No newline at end of file diff --git a/modules/olm-rukpak-bundle-immutability.adoc b/modules/olm-rukpak-bundle-immutability.adoc index 58061e90ee..628bba5ae5 100644 --- a/modules/olm-rukpak-bundle-immutability.adoc +++ b/modules/olm-rukpak-bundle-immutability.adoc @@ -65,4 +65,4 @@ If this scenario occurs, the new content from step 2 is unpacked as a result of This is similar to pod behavior, where one of the pod's container images uses a tag, the tag is moved to a different digest, and then at some point in the future the existing pod is rescheduled on a different node. At that point, the node pulls the new image at the new digest and runs something different without the user explicitly asking for it. -To be confident that the underlying `Bundle` spec content does not change, use a digest-based image or a Git commit reference when creating the bundle. \ No newline at end of file +To be confident that the underlying `Bundle` spec content does not change, use a digest-based image or a Git commit reference when creating the bundle. diff --git a/modules/olm-rukpak-bundle.adoc b/modules/olm-rukpak-bundle.adoc index 794648b642..57c65ee933 100644 --- a/modules/olm-rukpak-bundle.adoc +++ b/modules/olm-rukpak-bundle.adoc @@ -10,22 +10,7 @@ A RukPak `Bundle` object represents content to make available to other consumers Bundles cannot do anything on their own; they require a provisioner to unpack and make their content available in the cluster. They can be unpacked to any arbitrary storage medium, such as a `tar.gz` file in a directory mounted into the provisioner pods. Each `Bundle` object has an associated `spec.provisionerClassName` field that indicates the `Provisioner` object that watches and unpacks that particular bundle type. -.Example `Bundle` object configured to work with the plain provisioner -[source,yaml] ----- -apiVersion: core.rukpak.io/v1alpha1 -kind: Bundle -metadata: - name: my-bundle -spec: - source: - type: image - image: - ref: my-bundle@sha256:xyz123 - provisionerClassName: core-rukpak-io-plain ----- - [NOTE] ==== Bundles are considered immutable after they are created. -==== \ No newline at end of file +==== diff --git a/modules/olm-rukpak-provisioner.adoc b/modules/olm-rukpak-provisioner.adoc index ac32f804c9..1301f2ed99 100644 --- a/modules/olm-rukpak-provisioner.adoc +++ b/modules/olm-rukpak-provisioner.adoc @@ -9,8 +9,8 @@ RukPak consists of a series of controllers, known as _provisioners_, that install and manage content on a Kubernetes cluster. RukPak also provides two primary APIs: `Bundle` and `BundleDeployment`. These components work together to bring content onto the cluster and install it, generating resources within the cluster. -Two provisioners are currently implemented and bundled with RukPak: the _plain provisioner_ that sources and unpacks `plain+v0` bundles, and the _registry provisioner_ that sources and unpacks Operator Lifecycle Manager (OLM) `registry+v1` bundles. +Currently, the _registry provisioner_ is implemented and bundled with RukPak. The registry provisioner sources and unpacks Operator Lifecycle Manager (OLM) `registry+v1` bundles. -Each provisioner is assigned a unique ID and is responsible for reconciling `Bundle` and `BundleDeployment` objects with a `spec.provisionerClassName` field that matches that particular ID. For example, the plain provisioner is able to unpack a given `plain+v0` bundle onto a cluster and then instantiate it, making the content of the bundle available in the cluster. +A provisioner is assigned a unique ID and is responsible for reconciling `Bundle` and `BundleDeployment` objects with a `spec.provisionerClassName` field that matches that particular ID. For example, the registry provisioner is able to unpack a given `registry+v1` bundle onto a cluster and then instantiate it, making the content of the bundle available in the cluster. -A provisioner places a watch on both `Bundle` and `BundleDeployment` resources that refer to the provisioner explicitly. For a given bundle, the provisioner unpacks the contents of the `Bundle` resource onto the cluster. Then, given a `BundleDeployment` resource referring to that bundle, the provisioner installs the bundle contents and is responsible for managing the lifecycle of those resources. \ No newline at end of file +A provisioner places a watch on both `Bundle` and `BundleDeployment` resources that refer to the provisioner explicitly. For a given bundle, the provisioner unpacks the contents of the `Bundle` resource onto the cluster. Then, given a `BundleDeployment` resource referring to that bundle, the provisioner installs the bundle contents and is responsible for managing the lifecycle of those resources. diff --git a/modules/olmv1-creating-fbc.adoc b/modules/olmv1-creating-fbc.adoc index eed4a68498..e1478e6f91 100644 --- a/modules/olmv1-creating-fbc.adoc +++ b/modules/olmv1-creating-fbc.adoc @@ -1,6 +1,6 @@ // Module included in the following assemblies: // -// * operators/olm_v1/olmv1-plain-bundles.adoc +// * ifdef::openshift-origin[] :registry-image: quay.io/operator-framework/opm:latest diff --git a/operators/admin/olm-managing-po.adoc b/operators/admin/olm-managing-po.adoc deleted file mode 100644 index 4074cf1e24..0000000000 --- a/operators/admin/olm-managing-po.adoc +++ /dev/null @@ -1,55 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -[id="olm-managing-po"] -= Managing platform Operators (Technology Preview) -include::_attributes/common-attributes.adoc[] -:context: olm-managing-po - -toc::[] - -A platform Operator is an OLM-based Operator that can be installed during or after an OpenShift Container Platform cluster's Day 0 operations and participates in the cluster's lifecycle. As a cluster administrator, you can manage platform Operators by using the `PlatformOperator` API. - -:FeatureName: The platform Operator type -include::snippets/technology-preview.adoc[] - -include::modules/arch-platform-operators.adoc[leveloffset=+1] -[role="_additional-resources"] -.Additional resources - -* xref:../../operators/understanding/olm-packaging-format.adoc#olm-rukpak-about_olm-packaging-format[RukPak component and packaging format] -* xref:../../installing/cluster-capabilities.adoc#cluster-capabilities[Cluster capabilities] - -include::modules/olm-po-techpreview.adoc[leveloffset=+2] - -[id="prerequisites_olm-managing-po"] -== Prerequisites - -- Access to an {product-title} cluster using an account with `cluster-admin` permissions. -- The `TechPreviewNoUpgrade` feature set enabled on the cluster. -+ -[WARNING] -==== -Enabling the `TechPreviewNoUpgrade` feature set cannot be undone and prevents minor version updates. These feature sets are not recommended on production clusters. -==== -- Only the `redhat-operators` catalog source enabled on the cluster. This is a restriction during the Technology Preview release. -- The `oc` command installed on your workstation. - -[role="_additional-resources"] -.Additional resources - -* xref:../../nodes/clusters/nodes-cluster-enabling-features.adoc#nodes-cluster-enabling[Enabling features using feature gates] -* xref:../../operators/admin/olm-managing-custom-catalogs.adoc#olm-restricted-networks-operatorhub_olm-managing-custom-catalogs[Disabling the default OperatorHub catalog sources] - -include::modules/olm-installing-po-during.adoc[leveloffset=+1] -[role="_additional-resources"] -.Additional resources - -* xref:../../installing/installing-preparing.adoc#installing-preparing[Selecting a cluster installation method and preparing it for users] -* xref:../../operators/admin/olm-managing-po.adoc#olm-po-techpreview_olm-managing-po[Technology Preview restrictions for platform Operators] - -include::modules/olm-installing-po-after.adoc[leveloffset=+1] -[role="_additional-resources"] -.Additional resources - -* xref:../../operators/admin/olm-managing-po.adoc#olm-po-techpreview_olm-managing-po[Technology Preview restrictions for platform Operators] - -include::modules/olm-deleting-po.adoc[leveloffset=+1] \ No newline at end of file diff --git a/operators/olm_v1/arch/olmv1-components.adoc b/operators/olm_v1/arch/olmv1-components.adoc index dab015326d..0d8317b170 100644 --- a/operators/olm_v1/arch/olmv1-components.adoc +++ b/operators/olm_v1/arch/olmv1-components.adoc @@ -11,10 +11,10 @@ include::snippets/technology-preview.adoc[] {olmv1-first} comprises the following component projects: -Operator Controller:: xref:../../../operators/olm_v1/arch/olmv1-operator-controller.adoc#olmv1-operator-controller[Operator Controller] is the central component of {olmv1} that extends Kubernetes with an API through which users can install and manage the lifecycle of Operators and extensions. It consumes information from each of the following components. +Operator Controller:: xref:../../../operators/olm_v1/arch/olmv1-operator-controller.adoc#olmv1-operator-controller[Operator Controller] is the central component of {olmv1} that extends Kubernetes with an API through which users can install and manage the lifecycle of Operators and extensions. It consumes information from catalogd. RukPak:: xref:../../../operators/olm_v1/arch/olmv1-rukpak.adoc#olmv1-rukpak[RukPak] is a pluggable solution for packaging and distributing cloud-native content. It supports advanced strategies for installation, updates, and policy. + RukPak provides a content ecosystem for installing a variety of artifacts on a Kubernetes cluster. Artifact examples include Git repositories, Helm charts, and OLM bundles. RukPak can then manage, scale, and upgrade these artifacts in a safe way to enable powerful cluster extensions. -Catalogd:: xref:../../../operators/olm_v1/arch/olmv1-catalogd.adoc#olmv1-catalogd[Catalogd] is a Kubernetes extension that unpacks file-based catalog (FBC) content packaged and shipped in container images for consumption by on-cluster clients. As a component of the {olmv1} microservices architecture, catalogd hosts metadata for Kubernetes extensions packaged by the authors of the extensions, and as a result helps users discover installable content. \ No newline at end of file +Catalogd:: xref:../../../operators/olm_v1/arch/olmv1-catalogd.adoc#olmv1-catalogd[Catalogd] is a Kubernetes extension that unpacks file-based catalog (FBC) content packaged and shipped in container images for consumption by on-cluster clients. As a component of the {olmv1} microservices architecture, catalogd hosts metadata for Kubernetes extensions packaged by the authors of the extensions, and as a result helps users discover installable content. diff --git a/operators/olm_v1/arch/olmv1-dependency.adoc b/operators/olm_v1/arch/olmv1-dependency.adoc index d22382ba7b..bfd803a4b6 100644 --- a/operators/olm_v1/arch/olmv1-dependency.adoc +++ b/operators/olm_v1/arch/olmv1-dependency.adoc @@ -6,9 +6,9 @@ include::_attributes/common-attributes.adoc[] toc::[] -{olmv1-first} uses a dependency manager for resolving constraints over catalogs of RukPak bundles. +{olmv1-first} uses a dependency manager for resolving constraints over catalogs of bundles. :FeatureName: {olmv1} include::snippets/technology-preview.adoc[] -include::modules/olmv1-dependency-concepts.adoc[leveloffset=+1] \ No newline at end of file +include::modules/olmv1-dependency-concepts.adoc[leveloffset=+1] diff --git a/operators/olm_v1/arch/olmv1-operator-controller.adoc b/operators/olm_v1/arch/olmv1-operator-controller.adoc index 4f675da580..3d17717f13 100644 --- a/operators/olm_v1/arch/olmv1-operator-controller.adoc +++ b/operators/olm_v1/arch/olmv1-operator-controller.adoc @@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[] toc::[] -Operator Controller is the central component of {olmv1-first} and consumes the other {olmv1} components, RukPak and catalogd. It extends Kubernetes with an API through which users can install Operators and extensions. +Operator Controller is the central component of {olmv1-first} and consumes the other {olmv1} component, catalogd. It extends Kubernetes with an API through which users can install Operators and extensions. :FeatureName: {olmv1} include::snippets/technology-preview.adoc[] @@ -17,4 +17,4 @@ include::modules/olmv1-clusterextension-api.adoc[leveloffset=+1] * xref:../../../operators/understanding/olm/olm-colocation.adoc#olm-colocation[Operator Lifecycle Manager (OLM) -> Multitenancy and Operator colocation] -include::modules/olmv1-about-target-versions.adoc[leveloffset=+2] \ No newline at end of file +include::modules/olmv1-about-target-versions.adoc[leveloffset=+2] diff --git a/operators/olm_v1/arch/olmv1-rukpak.adoc b/operators/olm_v1/arch/olmv1-rukpak.adoc index bc455af6a6..1160dbcd5a 100644 --- a/operators/olm_v1/arch/olmv1-rukpak.adoc +++ b/operators/olm_v1/arch/olmv1-rukpak.adoc @@ -16,8 +16,8 @@ include::modules/olm-rukpak-provisioner.adoc[leveloffset=+1] include::modules/olm-rukpak-bundle.adoc[leveloffset=+1] include::modules/olm-rukpak-bundle-immutability.adoc[leveloffset=+2] -include::modules/olm-rukpak-plain-bundle.adoc[leveloffset=+2] include::modules/olm-rukpak-registry-bundle.adoc[leveloffset=+2] + [role="_additional-resources"] .Additional resources diff --git a/operators/olm_v1/index.adoc b/operators/olm_v1/index.adoc index e11f2d982c..ea263dd2df 100644 --- a/operators/olm_v1/index.adoc +++ b/operators/olm_v1/index.adoc @@ -39,13 +39,8 @@ Improved control over extension updates:: With improved insight into catalog content, administrators can specify target versions for installation and updates. This grants administrators more control over the target version of extension updates. For more information, see xref:../../operators/olm_v1/olmv1-installing-an-operator-from-a-catalog.adoc#olmv1-updating-an-operator_olmv1-installing-operator[Updating an Operator]. Flexible extension packaging format:: -Administrators can use file-based catalogs to install and manage the following types of content: +Administrators can use file-based catalogs to install and manage extensions, such as {olm}-based Operators, similar to the {olmv0} experience. + --- -* {olm}-based Operators, similar to the {olmv0} experience -* _Plain bundles_, which are static collections of arbitrary Kubernetes manifests --- -+ -In addition, bundle size is no longer constrained by the etcd value size limit. For more information, see xref:../../operators/olm_v1/olmv1-installing-an-operator-from-a-catalog.adoc#olmv1-installing-an-operator-from-a-catalog[Installing an Operator from a catalog] and xref:../../operators/olm_v1/olmv1-managing-plain-bundles.adoc#olmv1-managing-plain-bundles[Managing plain bundles]. +In addition, bundle size is no longer constrained by the etcd value size limit. For more information, see xref:../../operators/olm_v1/olmv1-installing-an-operator-from-a-catalog.adoc#olmv1-installing-an-operator-from-a-catalog[Installing an Operator from a catalog]. -include::modules/olmv1-about-purpose.adoc[leveloffset=+1] \ No newline at end of file +include::modules/olmv1-about-purpose.adoc[leveloffset=+1] diff --git a/operators/understanding/olm-packaging-format.adoc b/operators/understanding/olm-packaging-format.adoc index 105e9ca605..0ecdb1a6b8 100644 --- a/operators/understanding/olm-packaging-format.adoc +++ b/operators/understanding/olm-packaging-format.adoc @@ -83,7 +83,6 @@ include::modules/olm-rukpak-about.adoc[leveloffset=+1] include::modules/olm-rukpak-bundle.adoc[leveloffset=+2] include::modules/olm-rukpak-bundle-immutability.adoc[leveloffset=+3] -include::modules/olm-rukpak-plain-bundle.adoc[leveloffset=+3] include::modules/olm-rukpak-registry-bundle.adoc[leveloffset=+3] [role="_additional-resources"] .Additional resources diff --git a/snippets/olmv1-cli-only.adoc b/snippets/olmv1-cli-only.adoc index 2408aedfad..f53cb06dc9 100644 --- a/snippets/olmv1-cli-only.adoc +++ b/snippets/olmv1-cli-only.adoc @@ -1,7 +1,7 @@ // Text snippet included in the following modules: // // * operators/olm_v1/olmv1-installing-an-operator-from-a-catalog.adoc -// * operators/olm_v1/olmv1-managing-plain-bundles.adoc + :_mod-docs-content-type: SNIPPET