Merge pull request #76370 from michaelryanpeter/OSDOCS-10521-remove-plain-bundle-docs

michaelryanpeter · web-flow · commit 59fe7912ab63 · 2024-06-11T11:09:03.000-04:00
OSDOCS#10521: Remove plain bundle docs (TP)
diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml
@@ -1995,8 +1995,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/_unused_topics/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.
-====
+====
diff --git a/_unused_topics/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 <catalog_dir>
-----
+----
diff --git a/_unused_topics/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/<organization_name>/<repository_name>:<image_tag>
-----
+----
diff --git a/_unused_topics/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]
+include::modules/olmv1-publishing-fbc.adoc[leveloffset=+1]
diff --git a/modules/arch-platform-operators.adoc b/modules/arch-platform-operators.adoc
diff --git 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
-----
diff --git 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.
+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
@@ -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.
-====
+====
diff --git 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.
+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
@@ -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
diff --git 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.
+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
@@ -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]
+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
@@ -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]
+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
@@ -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
@@ -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]
+include::modules/olmv1-about-purpose.adoc[leveloffset=+1]
diff --git 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
@@ -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
 

Original file line number	Diff line number	Diff line change
`@@ -65,4 +65,4 @@ If this scenario occurs, the new content from step 2 is unpacked as a result of`
`65`	`65`
`66`	`66`	`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.`
`67`	`67`
`68`		-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.
	`68`	+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.