mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
Rm Bundle API from 4.16 OLMv1 TP
This commit is contained in:
Alex Dellapenta
committed by
openshift-cherrypick-robot
openshift-cherrypick-robot
parent
388be669ae
commit
0de8f08c1a
@@ -6,4 +6,4 @@
|
||||
[id="olm-rukpak-registry-bundle_{context}"]
|
||||
= Registry bundle spec
|
||||
|
||||
A registry bundle, or `registry+v1` bundle, contains a set of static Kubernetes YAML manifests organized in the legacy Operator Lifecycle Manager (OLM) bundle format.
|
||||
A registry bundle, or `registry+v1` bundle, contains a set of static Kubernetes YAML manifests organized in the {olmv0-first} bundle format.
|
||||
@@ -19,9 +19,9 @@ endif::[]
|
||||
|
||||
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.
|
||||
RukPak provides a content ecosystem for installing artifacts on a Kubernetes cluster. In {product-title} 4.16, RukPak supports {olmv0-first} bundles as artifacts. RukPak can then manage, scale, and upgrade these artifacts in a safe way to enable powerful cluster extensions.
|
||||
|
||||
At its core, RukPak is a small set of APIs and controllers. The APIs are packaged as custom resource definitions (CRDs) that express what content to install on a cluster and how to create a running deployment of the content. The controllers watch for the APIs.
|
||||
At its core, RukPak is a set of controllers and the `BundleDeployment` API. The API is packaged as a custom resource definition (CRD) that expresses what content to install on a cluster and how to create a running deployment of the content. The controllers watch for the API.
|
||||
|
||||
.Common terminology
|
||||
|
||||
@@ -34,4 +34,4 @@ A Git repository that contains a bundle within a directory
|
||||
Provisioner::
|
||||
Controllers that install and manage content on a Kubernetes cluster
|
||||
Bundle deployment::
|
||||
Generates deployed instances of a bundle
|
||||
Generates deployed instances of a bundle
|
||||
@@ -6,13 +6,13 @@
|
||||
[id="olm-rukpak-bd_{context}"]
|
||||
= BundleDeployment
|
||||
|
||||
In {product-title} 4.16, the RukPak `BundleDeployment` indicates when a bundle should be active. This includes pivoting from older versions of an active bundle.
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
A `BundleDeployment` object changes the state of a Kubernetes cluster by installing and removing objects. It is important to verify and trust the content that is being installed and limit access, by using RBAC, to the `BundleDeployment` API to only those who require those permissions.
|
||||
====
|
||||
|
||||
The RukPak `BundleDeployment` API points to a `Bundle` object and indicates that it should be active. This includes pivoting from older versions of an active bundle. A `BundleDeployment` object might also include an embedded spec for a desired bundle.
|
||||
|
||||
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.
|
||||
|
||||
@@ -7,10 +7,11 @@
|
||||
[id="olm-rukpak-provisioner_{context}"]
|
||||
= About provisioners
|
||||
|
||||
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.
|
||||
RukPak consists of a series of controllers, known as _provisioners_, that install and manage content on a Kubernetes cluster. A provisioner works together with a `BundleDeployment` object to bring content onto the cluster and install it, generating resources within the cluster.
|
||||
|
||||
Currently, the _registry provisioner_ is implemented and bundled with RukPak. The registry provisioner sources and unpacks Operator Lifecycle Manager (OLM) `registry+v1` bundles.
|
||||
Currently, the _registry provisioner_ is implemented and included with RukPak. A _registry bundle_, or `registry+v1` bundle, contains a set of static Kubernetes YAML manifests organized in the {olmv0-first} bundle format. The registry provisioner sources and unpacks registry bundles.
|
||||
|
||||
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 is assigned a unique ID and is responsible for reconciling bundles 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 `BundleDeployment` resources that refer to the provisioner explicitly. For a given bundle, the provisioner unpacks the contents of the bundle 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.
|
||||
|
||||
@@ -14,7 +14,5 @@ include::snippets/technology-preview.adoc[]
|
||||
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.
|
||||
|
||||
@@ -13,14 +13,9 @@ include::snippets/technology-preview.adoc[]
|
||||
|
||||
include::modules/olm-rukpak-about.adoc[leveloffset=+1]
|
||||
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-registry-bundle.adoc[leveloffset=+2]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* xref:../../../operators/understanding/olm-packaging-format.adoc#olm-bundle-format_olm-packaging-format[Legacy OLM bundle format]
|
||||
* xref:../../../operators/understanding/olm-packaging-format.adoc#olm-bundle-format_olm-packaging-format[{olmv0-caps} bundle format]
|
||||
|
||||
include::modules/olm-rukpak-bd.adoc[leveloffset=+1]
|
||||
|
||||
@@ -79,17 +79,9 @@ include::modules/olm-rukpak-about.adoc[leveloffset=+1]
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* xref:../../operators/olm_v1/index.adoc#olmv1-about[About Operator Lifecycle Manager 1.0 (Technology Preview)]
|
||||
|
||||
include::modules/olm-rukpak-bundle.adoc[leveloffset=+2]
|
||||
include::modules/olm-rukpak-bundle-immutability.adoc[leveloffset=+3]
|
||||
include::modules/olm-rukpak-registry-bundle.adoc[leveloffset=+3]
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* xref:../../operators/understanding/olm-packaging-format.adoc#olm-bundle-format_olm-packaging-format[Legacy OLM bundle format]
|
||||
|
||||
include::modules/olm-rukpak-bd.adoc[leveloffset=+2]
|
||||
* xref:../../operators/olm_v1/index.adoc#olmv1-about[About {olmv1} (Technology Preview)]
|
||||
* xref:../../operators/understanding/olm-packaging-format.adoc#olm-bundle-format_olm-packaging-format[{olmv0-caps} bundle format]
|
||||
|
||||
include::modules/olm-rukpak-provisioner.adoc[leveloffset=+2]
|
||||
include::modules/olm-rukpak-bd.adoc[leveloffset=+2]
|
||||
endif::openshift-dedicated,openshift-rosa[]
|
||||
|
||||
Reference in New Issue
Block a user