mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
OSDOCS-10534: Deprecate Operator SDK and associated features
This commit is contained in:
Michael Ryan Peter
committed by
openshift-cherrypick-robot
openshift-cherrypick-robot
parent
cf0921ee23
commit
78c3fc4995
@@ -8,6 +8,8 @@ toc::[]
|
||||
|
||||
The Operator SDK provides a command-line interface (CLI) tool that Operator developers can use to build, test, and deploy an Operator. You can install the Operator SDK CLI on your workstation so that you are prepared to start authoring your own Operators.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
Operator authors with cluster administrator access to a Kubernetes-based cluster, such as {product-title}, can use the Operator SDK CLI to develop their own Operators based on Go, Ansible, Java, or Helm. link:https://kubebuilder.io/[Kubebuilder] is embedded into the Operator SDK as the scaffolding solution for Go-based Operators, which means existing Kubebuilder projects can be used as is with the Operator SDK and continue to work.
|
||||
ifndef::openshift-rosa,openshift-dedicated[]
|
||||
See xref:../../operators/operator_sdk/osdk-about.adoc#osdk-about[Developing Operators] for full documentation on the Operator SDK.
|
||||
@@ -20,4 +22,4 @@ endif::openshift-rosa,openshift-dedicated[]
|
||||
|
||||
include::modules/osdk-installing-cli-linux-macos.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/osdk-installing-cli-macos.adoc[leveloffset=+1]
|
||||
include::modules/osdk-installing-cli-macos.adoc[leveloffset=+1]
|
||||
|
||||
@@ -8,6 +8,8 @@ toc::[]
|
||||
|
||||
The Operator SDK command-line interface (CLI) is a development kit designed to make writing Operators easier.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
.Operator SDK CLI syntax
|
||||
[source,terminal]
|
||||
----
|
||||
@@ -51,4 +53,4 @@ ifndef::openshift-rosa,openshift-dedicated[]
|
||||
.Additional resources
|
||||
|
||||
* See xref:../../operators/operator_sdk/osdk-scorecard.adoc#osdk-scorecard[Validating Operators using the scorecard tool] for details about running the scorecard tool.
|
||||
endif::openshift-rosa,openshift-dedicated[]
|
||||
endif::openshift-rosa,openshift-dedicated[]
|
||||
|
||||
@@ -6,5 +6,7 @@ include::_attributes/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-ansible-cr-status-about.adoc[leveloffset=+1]
|
||||
include::modules/osdk-ansible-cr-status-manual.adoc[leveloffset=+1]
|
||||
|
||||
@@ -8,6 +8,8 @@ toc::[]
|
||||
|
||||
After you are familiar with xref:../../../operators/operator_sdk/ansible/osdk-ansible-k8s-collection.adoc#osdk-ansible-k8s-collection[using the Kubernetes Collection for Ansible locally], you can trigger the same Ansible logic inside of an Operator when a custom resource (CR) changes. This example maps an Ansible role to a specific Kubernetes resource that the Operator watches. This mapping is done in the `watches.yaml` file.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-ansible-custom-resource-files.adoc[leveloffset=+1]
|
||||
include::modules/osdk-ansible-inside-operator-local.adoc[leveloffset=+1]
|
||||
include::modules/osdk-run-deployment.adoc[leveloffset=+1]
|
||||
|
||||
@@ -8,6 +8,8 @@ toc::[]
|
||||
|
||||
To manage the lifecycle of your application on Kubernetes using Ansible, you can use the link:https://galaxy.ansible.com/community/kubernetes[Kubernetes Collection for Ansible]. This collection of Ansible modules allows a developer to either leverage their existing Kubernetes resource files written in YAML or express the lifecycle management in native Ansible.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
One of the biggest benefits of using Ansible in conjunction with existing Kubernetes resource files is the ability to use Jinja templating so that you can customize resources with the simplicity of a few variables in Ansible.
|
||||
|
||||
This section goes into detail on usage of the Kubernetes Collection. To get started, install the collection on your local workstation and test it using a playbook before moving on to using it within an Operator.
|
||||
|
||||
@@ -8,4 +8,6 @@ toc::[]
|
||||
|
||||
The `operator-sdk` CLI can generate, or _scaffold_, a number of packages and files for each Operator project.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-ansible-project-layout.adoc[leveloffset=+1]
|
||||
|
||||
@@ -10,6 +10,8 @@ toc::[]
|
||||
|
||||
The Operator SDK includes options for generating an Operator project that leverages existing Ansible playbooks and modules to deploy Kubernetes resources as a unified application, without having to write any Go code.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
To demonstrate the basics of setting up and running an link:https://docs.ansible.com/ansible/latest/index.html[Ansible]-based Operator using tools and libraries provided by the Operator SDK, Operator developers can build an example Ansible-based Operator for Memcached, a distributed key-value store, and deploy it to a cluster.
|
||||
|
||||
include::modules/osdk-common-prereqs.adoc[leveloffset=+1]
|
||||
|
||||
@@ -6,6 +6,8 @@ include::_attributes/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-ansible-custom-resource-files.adoc[leveloffset=+1]
|
||||
include::modules/osdk-ansible-watches-file.adoc[leveloffset=+1]
|
||||
include::modules/osdk-ansible-extra-variables.adoc[leveloffset=+1]
|
||||
|
||||
@@ -12,6 +12,8 @@ Operator developers can take advantage of link:https://docs.ansible.com/ansible/
|
||||
* Ensure that the deployment size is the same as specified by the `Memcached` custom resource (CR) spec
|
||||
* Update the `Memcached` CR status using the status writer with the names of the `memcached` pods
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
This process is accomplished by using two centerpieces of the Operator Framework:
|
||||
|
||||
Operator SDK:: The `operator-sdk` CLI tool and `controller-runtime` library API
|
||||
|
||||
@@ -8,6 +8,8 @@ toc::[]
|
||||
|
||||
{product-title} {product-version} supports Operator SDK {osdk_ver}. If you already have the {osdk_ver_n1} CLI installed on your workstation, you can update the CLI to {osdk_ver} by xref:../../../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[installing the latest version].
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
However, to ensure your existing Operator projects maintain compatibility with Operator SDK {osdk_ver}, update steps are required for the associated breaking changes introduced since {osdk_ver_n1}. You must perform the update steps manually in any of your Operator projects that were previously created or maintained with {osdk_ver_n1}.
|
||||
|
||||
include::modules/osdk-updating-128-to-131.adoc[leveloffset=+1]
|
||||
|
||||
@@ -8,4 +8,6 @@ toc::[]
|
||||
|
||||
The `operator-sdk` CLI can generate, or _scaffold_, a number of packages and files for each Operator project.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-golang-project-layout.adoc[leveloffset=+1]
|
||||
|
||||
@@ -10,6 +10,8 @@ toc::[]
|
||||
|
||||
To demonstrate the basics of setting up and running a Go-based Operator using tools and libraries provided by the Operator SDK, Operator developers can build an example Go-based Operator for Memcached, a distributed key-value store, and deploy it to a cluster.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-common-prereqs.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
|
||||
@@ -8,6 +8,8 @@ toc::[]
|
||||
|
||||
Operator developers can take advantage of Go programming language support in the Operator SDK to build an example Go-based Operator for Memcached, a distributed key-value store, and manage its lifecycle.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
This process is accomplished using two centerpieces of the Operator Framework:
|
||||
|
||||
Operator SDK:: The `operator-sdk` CLI tool and `controller-runtime` library API
|
||||
@@ -89,4 +91,4 @@ ifndef::openshift-dedicated,openshift-rosa[]
|
||||
endif::openshift-dedicated,openshift-rosa[]
|
||||
ifdef::openshift-dedicated,openshift-rosa[]
|
||||
* If a xref:../../../networking/configuring-cluster-wide-proxy.adoc#configuring-a-cluster-wide-proxy[cluster-wide egress proxy is configured], administrators with the `dedicated-admin` role can xref:../../../operators/admin/olm-configuring-proxy-support.adoc#olm-configuring-proxy-support[override the proxy settings or inject a custom CA certificate] for specific Operators running on Operator Lifecycle Manager (OLM).
|
||||
endif::openshift-dedicated,openshift-rosa[]
|
||||
endif::openshift-dedicated,openshift-rosa[]
|
||||
|
||||
@@ -8,6 +8,8 @@ toc::[]
|
||||
|
||||
{product-title} {product-version} supports Operator SDK {osdk_ver}. If you already have the {osdk_ver_n1} CLI installed on your workstation, you can update the CLI to {osdk_ver} by xref:../../../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[installing the latest version].
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
However, to ensure your existing Operator projects maintain compatibility with Operator SDK {osdk_ver}, update steps are required for the associated breaking changes introduced since {osdk_ver_n1}. You must perform the update steps manually in any of your Operator projects that were previously created or maintained with {osdk_ver_n1}.
|
||||
|
||||
include::modules/osdk-updating-128-to-131.adoc[leveloffset=+1]
|
||||
|
||||
@@ -8,4 +8,6 @@ toc::[]
|
||||
|
||||
The `operator-sdk` CLI can generate, or _scaffold_, a number of packages and files for each Operator project.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-helm-project-layout.adoc[leveloffset=+1]
|
||||
|
||||
@@ -10,6 +10,8 @@ toc::[]
|
||||
|
||||
The Operator SDK includes options for generating an Operator project that leverages existing link:https://helm.sh/docs/[Helm] charts to deploy Kubernetes resources as a unified application, without having to write any Go code.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
To demonstrate the basics of setting up and running an link:https://helm.sh/docs/[Helm]-based Operator using tools and libraries provided by the Operator SDK, Operator developers can build an example Helm-based Operator for Nginx and deploy it to a cluster.
|
||||
|
||||
include::modules/osdk-common-prereqs.adoc[leveloffset=+1]
|
||||
|
||||
@@ -6,4 +6,6 @@ include::_attributes/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-helm-charts.adoc[leveloffset=+1]
|
||||
|
||||
@@ -12,6 +12,8 @@ Operator developers can take advantage of link:https://helm.sh/docs/[Helm] suppo
|
||||
* Ensure that the deployment size is the same as specified by the `Nginx` custom resource (CR) spec
|
||||
* Update the `Nginx` CR status using the status writer with the names of the `nginx` pods
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
This process is accomplished using two centerpieces of the Operator Framework:
|
||||
|
||||
Operator SDK:: The `operator-sdk` CLI tool and `controller-runtime` library API
|
||||
|
||||
@@ -8,6 +8,8 @@ toc::[]
|
||||
|
||||
{product-title} {product-version} supports Operator SDK {osdk_ver}. If you already have the {osdk_ver_n1} CLI installed on your workstation, you can update the CLI to {osdk_ver} by xref:../../../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[installing the latest version].
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
However, to ensure your existing Operator projects maintain compatibility with Operator SDK {osdk_ver}, update steps are required for the associated breaking changes introduced since {osdk_ver_n1}. You must perform the update steps manually in any of your Operator projects that were previously created or maintained with {osdk_ver_n1}.
|
||||
|
||||
include::modules/osdk-updating-128-to-131.adoc[leveloffset=+1]
|
||||
|
||||
@@ -8,6 +8,8 @@ toc::[]
|
||||
|
||||
{product-title} {product-version} supports Operator SDK {osdk_ver}. If you already have the {osdk_ver_n1} CLI installed on your workstation, you can update the CLI to {osdk_ver} by xref:../../../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[installing the latest version].
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
However, to ensure your existing Operator projects maintain compatibility with Operator SDK {osdk_ver}, update steps are required for the associated breaking changes introduced since {osdk_ver_n1}. You must perform the update steps manually in any of your Operator projects that were previously created or maintained with {osdk_ver_n1}.
|
||||
|
||||
include::modules/osdk-updating-128-to-131.adoc[leveloffset=+1]
|
||||
|
||||
@@ -8,6 +8,8 @@ toc::[]
|
||||
|
||||
The standard Helm-based Operator support in the Operator SDK has limited functionality compared to the Go-based and Ansible-based Operator support that has reached the Auto Pilot capability (level V) in the xref:../../../operators/understanding/olm-what-operators-are.adoc#olm-maturity-model_olm-what-operators-are[Operator maturity model].
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
The Hybrid Helm Operator enhances the existing Helm-based support's abilities through Go APIs. With this hybrid approach of Helm and Go, the Operator SDK enables Operator authors to use the following process:
|
||||
|
||||
* Generate a default structure for, or _scaffold_, a Go API in the same project as Helm.
|
||||
|
||||
@@ -10,4 +10,6 @@ toc::[]
|
||||
|
||||
The `operator-sdk` CLI can generate, or _scaffold_, a number of packages and files for each Operator project.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-java-project-layout.adoc[leveloffset=+1]
|
||||
|
||||
@@ -12,6 +12,8 @@ toc::[]
|
||||
|
||||
To demonstrate the basics of setting up and running a Java-based Operator using tools and libraries provided by the Operator SDK, Operator developers can build an example Java-based Operator for Memcached, a distributed key-value store, and deploy it to a cluster.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-common-prereqs.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
|
||||
@@ -12,6 +12,8 @@ toc::[]
|
||||
|
||||
Operator developers can take advantage of Java programming language support in the Operator SDK to build an example Java-based Operator for Memcached, a distributed key-value store, and manage its lifecycle.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
This process is accomplished using two centerpieces of the Operator Framework:
|
||||
|
||||
Operator SDK:: The `operator-sdk` CLI tool and `java-operator-sdk` library API
|
||||
|
||||
@@ -8,6 +8,8 @@ toc::[]
|
||||
|
||||
{product-title} {product-version} supports Operator SDK {osdk_ver}. If you already have the {osdk_ver_n1} CLI installed on your workstation, you can update the CLI to {osdk_ver} by xref:../../../operators/operator_sdk/osdk-installing-cli.adoc#osdk-installing-cli[installing the latest version].
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
However, to ensure your existing Operator projects maintain compatibility with Operator SDK {osdk_ver}, update steps are required for the associated breaking changes introduced since {osdk_ver_n1}. You must perform the update steps manually in any of your Operator projects that were previously created or maintained with {osdk_ver_n1}.
|
||||
|
||||
include::modules/osdk-updating-128-to-131.adoc[leveloffset=+1]
|
||||
|
||||
@@ -12,6 +12,8 @@ Operators make it easy to manage complex, stateful applications on top of Kubern
|
||||
|
||||
The Operator SDK, a component of the Operator Framework, provides a command-line interface (CLI) tool that Operator developers can use to build, test, and deploy an Operator.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
**Why use the Operator SDK?**
|
||||
|
||||
The Operator SDK simplifies this process of building Kubernetes-native applications, which can require deep, application-specific operational knowledge. The Operator SDK not only lowers that barrier, but it also helps reduce the amount of boilerplate code required for many common management capabilities, such as metering or monitoring.
|
||||
|
||||
@@ -8,6 +8,8 @@ toc::[]
|
||||
|
||||
As an Operator author, you can run the `bundle validate` command in the Operator SDK to validate the content and format of an Operator bundle. You can run the command on a remote Operator bundle image or a local Operator bundle directory.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-bundle-validate-about.adoc[leveloffset=+1]
|
||||
include::modules/osdk-bundle-validate-tests.adoc[leveloffset=+1]
|
||||
|
||||
|
||||
@@ -8,6 +8,8 @@ toc::[]
|
||||
|
||||
The Operator SDK command-line interface (CLI) is a development kit designed to make writing Operators easier.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
.Operator SDK CLI syntax
|
||||
[source,terminal]
|
||||
----
|
||||
|
||||
@@ -16,6 +16,8 @@ If your Operator project does not require escalated permissions to run, you can
|
||||
|
||||
For more information, see xref:../../authentication/understanding-and-managing-pod-security-admission.adoc#understanding-and-managing-pod-security-admission[Understanding and managing pod security admission].
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
// About pod security admission
|
||||
include::modules/security-context-constraints-psa-about.adoc[leveloffset=+1]
|
||||
|
||||
|
||||
@@ -10,6 +10,8 @@ A _cluster service version_ (CSV), defined by a `ClusterServiceVersion` object,
|
||||
|
||||
The Operator SDK includes the CSV generator to generate a CSV for the current Operator project, customized using information contained in YAML manifests and Operator source files.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
A CSV-generating command removes the responsibility of Operator authors having in-depth OLM knowledge in order for their Operator to interact with OLM or publish metadata to the Catalog Registry. Further, because the CSV spec will likely change over time as new Kubernetes and OLM features are implemented, the Operator SDK is equipped to easily extend its update system to handle new CSV features going forward.
|
||||
|
||||
include::modules/osdk-how-csv-gen-works.adoc[leveloffset=+1]
|
||||
|
||||
@@ -16,5 +16,7 @@ An OpenShift Container Platform cluster can be configured in high-availability (
|
||||
|
||||
By accessing the cluster high-availability mode API provided in {product-title}, Operator authors can use the Operator SDK to enable their Operator to detect a cluster's infrastructure topology, either HA or non-HA mode. Custom Operator logic can be developed that uses the detected cluster topology to automatically switch the resource requirements, both for the Operator and for any Operands or workloads it manages, to a profile that best fits the topology.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-ha-sno-api.adoc[leveloffset=+1]
|
||||
include::modules/osdk-ha-sno-api-examples.adoc[leveloffset=+1]
|
||||
|
||||
@@ -8,6 +8,8 @@ toc::[]
|
||||
|
||||
The Operator SDK provides a command-line interface (CLI) tool that Operator developers can use to build, test, and deploy an Operator. You can install the Operator SDK CLI on your workstation so that you are prepared to start authoring your own Operators.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
ifndef::openshift-dedicated,openshift-rosa[]
|
||||
Operator authors with cluster administrator access to a Kubernetes-based cluster, such as {product-title},
|
||||
endif::openshift-dedicated,openshift-rosa[]
|
||||
|
||||
@@ -16,4 +16,6 @@ Leader-with-lease:: The leader pod periodically renews the leader lease and give
|
||||
|
||||
By default, the Operator SDK enables the Leader-for-life implementation. Consult the related Go documentation for both approaches to consider the trade-offs that make sense for your use case.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-leader-election-types.adoc[leveloffset=+1]
|
||||
|
||||
@@ -8,6 +8,8 @@ toc::[]
|
||||
|
||||
This guide describes how to migrate an Operator project built using Operator SDK v0.0.x to the project structure required by link:https://github.com/operator-framework/operator-sdk/releases[Operator SDK v0.1.0].
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
The recommended method for migrating your project is to:
|
||||
|
||||
. Initialize a new v0.1.0 project.
|
||||
|
||||
@@ -11,6 +11,8 @@ toc::[]
|
||||
ifndef::openshift-dedicated,openshift-rosa[]
|
||||
This guide describes the built-in monitoring support provided by the Operator SDK using the Prometheus Operator and details usage for authors of Go-based and Ansible-based Operators.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-monitoring-prometheus-operator-support.adoc[leveloffset=+1]
|
||||
include::modules/osdk-monitoring-custom-metrics.adoc[leveloffset=+1]
|
||||
include::modules/osdk-ansible-metrics.adoc[leveloffset=+1]
|
||||
@@ -20,6 +22,8 @@ ifdef::openshift-dedicated,openshift-rosa[]
|
||||
// Since OSD/ROSA dedicated-admins can't do the procedures in this assembly, point to the OCP docs.
|
||||
The Operator SDK provides built-in monitoring support using the Prometheus Operator, which you can use to expose custom metrics for your Operator.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
By default, {product-title} provides a Prometheus Operator in the `openshift-user-workload-monitoring` project. You should use this Prometheus instance to monitor user workloads in {product-title}.
|
||||
|
||||
@@ -13,6 +13,8 @@ Perform the following actions to ensure your Operator project can run on multipl
|
||||
* Build a manifest list that specifies the platforms that your Operator supports.
|
||||
* Set your Operator's node affinity to support multi-architecture compute machines.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-multi-arch-building-images.adoc[leveloffset=+1]
|
||||
include::modules/osdk-multi-arch-node-affinity.adoc[leveloffset=+1]
|
||||
|
||||
|
||||
@@ -9,6 +9,8 @@ toc::[]
|
||||
Support for the legacy _package manifest format_ for Operators is removed in {product-title} 4.8 and later. If you have an Operator project that was initially created using the package manifest format, 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.
|
||||
//Consider updating this during the 4.10 to 4.11 version scrub.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-about-pkg-format-migration.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
|
||||
@@ -8,5 +8,7 @@ toc::[]
|
||||
|
||||
The `operator-lib` pruning utility lets Go-based Operators clean up, or prune, objects when they are no longer needed. Operator authors can also use the utility to create custom hooks and strategies.
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-pruning-utility-about.adoc[leveloffset=+1]
|
||||
include::modules/osdk-pruning-utility-config.adoc[leveloffset=+1]
|
||||
|
||||
@@ -11,6 +11,8 @@ As an Operator author, you can use the scorecard tool in the Operator SDK to do
|
||||
* Validate that your Operator project is free of syntax errors and packaged correctly
|
||||
* Review suggestions about ways you can improve your Operator
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-scorecard-about.adoc[leveloffset=+1]
|
||||
include::modules/osdk-scorecard-config.adoc[leveloffset=+1]
|
||||
include::modules/osdk-scorecard-tests.adoc[leveloffset=+1]
|
||||
|
||||
@@ -8,6 +8,8 @@ toc::[]
|
||||
|
||||
You can use the Operator SDK to package, deploy, and upgrade Operators in the bundle format for use on Operator Lifecycle Manager (OLM).
|
||||
|
||||
include::snippets/osdk-deprecation.adoc[]
|
||||
|
||||
include::modules/osdk-bundle-operator.adoc[leveloffset=+1]
|
||||
include::modules/osdk-deploy-olm.adoc[leveloffset=+1]
|
||||
|
||||
|
||||
60
snippets/osdk-deprecation.adoc
Normal file
60
snippets/osdk-deprecation.adoc
Normal file
@@ -0,0 +1,60 @@
|
||||
// Text snippet included in the following assemblies:
|
||||
// * cli_reference/osdk/cli-osdk-install.adoc
|
||||
// * cli_reference/osdk/cli-osdk-ref.adoc
|
||||
// * operators/operator_sdk/ansible/osdk-ansible-cr-status.adoc
|
||||
// * operators/operator_sdk/ansible/osdk-ansible-inside-operator.adoc
|
||||
// * operators/operator_sdk/ansible/osdk-ansible-k8s-collection.adoc
|
||||
// * operators/operator_sdk/ansible/osdk-ansible-project-layout.adoc
|
||||
// * opearotors/operator_sdk/ansible/osdk-ansible-quickstart.adoc
|
||||
// * operators/operator_sdk/ansible/osdk-ansible-support.adoc
|
||||
// * operators/operator_sdk/ansible/osdk-ansible-tutorial.adoc
|
||||
// * operators/ansible/osdk-ansible-updating-projects.adoc
|
||||
// * operator/operator_sdk/golang/osdk-golang-project-layout.adoc
|
||||
// * operators/operator_sdk/golang/osdk-golang-quickstart.adoc
|
||||
// * operators/operator_sdk/golang/osdk-golang-tutorial.adoc
|
||||
// * operators/operator_sdk/golang/osdk-golang-updating-projects.adoc
|
||||
// * operators/operator_sdk/helm/osdk-helm-project-layout.adoc
|
||||
// * operators/operator_sdk/helm/osdk-helm-quickstart.adoc
|
||||
// * operators/operator_sdk/helm/osdk-helm-support.adoc
|
||||
// * operators/operator_sdk/helm/osdk-helm-tutorial.adoc
|
||||
// * operators/operator_sdk/helm/osdk-helm-updating-projects.adoc
|
||||
// * operators/operator_sdk/helm/osdk-hybrid-helm-updating-projects.adoc
|
||||
// * operators/operator_sdk/helm/osdk-hybrid-helm.adoc
|
||||
// * operators/operator_sdk/java/osdk-java-project-layout.adoc
|
||||
// * operators/operator_sdk/java/osdk-java-quickstart.adoc
|
||||
// * operators/operator_sdk/java/osdk-java-tutorial.adoc
|
||||
// * operators/operator_sdk/java/osdk-java-updating-projects.adoc
|
||||
// * operators/operator_sdk/osdk-about.adoc
|
||||
// * operators/operator_sdk/osdk-bundle-validate.adoc
|
||||
// * operators/operator_sdk/osdk-cli-ref.adoc
|
||||
// * operators/operator_sdk/osdk-complying-with-psa.adoc
|
||||
// * operators/operator_sdk/osdk-generating-csvs.adoc
|
||||
// * operators/operator_sdk/osdk-ha-sno.adoc
|
||||
// * operators/operator_sdk/osdk-installing-cli.adoc
|
||||
// * operators/operator_sdk/osdk-leader-election.adoc
|
||||
// * operators/operator_sdk/osdk-migrating-to-v0-1-0.adoc
|
||||
// * operators/operator_sdk/osdk-monitoring-prometheus.adoc
|
||||
// * operators/operator_sdk/osdk-multi-arch-support.adoc
|
||||
// * operators/operator_sdk/osdk-pkgman-to-bundle.adoc
|
||||
// * operators/operator_sdk/osdk-pruning-utility.adoc
|
||||
// * operators/operator_sdk/osdk-scorecard.adoc
|
||||
// * operators/operator_sdk/osdk-working-bundle-images.adoc
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
[subs="attributes+"]
|
||||
The Red{nbsp}Hat-supported version of the Operator SDK CLI tool, including the related scaffolding and testing tools for Operator projects, is deprecated and is planned to be removed in a future release of {product-title}. Red{nbsp}Hat will provide bug fixes and support for this feature during the current release lifecycle, but this feature will no longer receive enhancements and will be removed from future {product-title} releases.
|
||||
|
||||
The Red{nbsp}Hat-supported version of the Operator SDK is not recommended for creating new Operator projects. Operator authors with existing Operator projects can use the version of the Operator SDK CLI tool released with {product-title} {product-version} to maintain their projects and create Operator releases targeting newer versions of {product-title}.
|
||||
|
||||
The following related base images for Operator projects are _not_ deprecated. The runtime functionality and configuration APIs for these base images are still supported for bug fixes and for addressing CVEs.
|
||||
|
||||
* The base image for Ansible-based Operator projects
|
||||
* The base image for Helm-based Operator projects
|
||||
|
||||
ifndef::openshift-rosa,openshift-dedicated[]
|
||||
For the most recent list of major functionality that has been deprecated or removed within {product-title}, refer to the _Deprecated and removed features_ section of the {product-title} release notes.
|
||||
endif::openshift-rosa,openshift-dedicated[]
|
||||
|
||||
For information about the unsupported, community-maintained, version of the Operator SDK, see link:https://sdk.operatorframework.io[Operator SDK (Operator Framework)].
|
||||
====
|
||||
Reference in New Issue
Block a user