1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00

OCPBUGS-499969: Removed 4.10 and 4.11 references from MetalLB docs

This commit is contained in:
dfitzmau
2025-03-05 12:55:46 +00:00
committed by openshift-cherrypick-robot
parent 71c4bbe175
commit bd5f75cc12
7 changed files with 99 additions and 279 deletions

View File

@@ -3,61 +3,100 @@
// * networking/metallb/metallb-upgrading-operator.adoc
:_mod-docs-content-type: PROCEDURE
[id="upgrading-metallb-operator_{context}"]
= Upgrading the MetalLB Operator
= Manually upgrading the MetalLB Operator
To manually control upgrading the MetalLB Operator, you must edit the `Subscription` custom resource (CR) that subscribes the namespace to `metallb-system`. A `Subscription` CR is created as part of the Operator installation and the CR has the `installPlanApproval` parameter set to `Automatic` by default.
.Prerequisites
* You updated your cluster to the latest z-stream release.
* You used OperatorHub to install the MetalLB Operator.
* Access the cluster as a user with the `cluster-admin` role.
.Procedure
. Verify that the `metallb-system` namespace still exists:
. Get the YAML definition of the `metallb-operator` subscription in the `metallb-system` namespace by entering the following command:
+
[source,terminal]
----
$ oc get namespaces | grep metallb-system
----
+
.Example output
[source,terminal]
----
metallb-system Active 31m
$ oc -n metallb-system get subscription metallb-operator -o yaml
----
. Verify the `metallb` custom resource still exists:
. Edit the `Subscription` CR by setting the `installPlanApproval` parameter to `Manual`:
+
[source,terminal]
[source,yaml]
----
$ oc get metallb -n metallb-system
----
+
.Example output
[source,terminal]
----
NAME AGE
metallb 33m
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: metallb-operator
namespace: metallb-system
# ...
spec:
channel: stable
installPlanApproval: Manual
name: metallb-operator
source: redhat-operators
sourceNamespace: openshift-marketplace
# ...
----
. Follow the guidance in "Installing from OperatorHub using the CLI" to install the latest {product-version} version of the MetalLB Operator.
+
[NOTE]
====
When installing the latest {product-version} version of the MetalLB Operator, you must install the Operator to the same namespace it was previously installed to.
====
. Verify the upgraded version of the Operator is now the {product-version} version.
. Find the latest {product-title} {product-version} version of the MetalLB Operator by entering the following command:
+
[source,terminal]
----
$ oc get csv -n metallb-system
$ oc -n metallb-system get csv
----
+
.Example output
[source,terminal,subs="attributes+"]
----
NAME DISPLAY VERSION REPLACES PHASE
metallb-operator.{product-version}.0-202207051316 MetalLB Operator {product-version}.0-202207051316 Succeeded
NAME DISPLAY VERSION REPLACES PHASE
metallb-operator.v{product-version}.0 MetalLB Operator {product-version}.0 Succeeded
----
. Check the install plan that exists in the namespace by entering the following command.
+
[source,terminal]
----
$ oc -n metallb-system get installplan
----
+
.Example output that shows install-tsz2g as a manual install plan
[source,terminal,subs="attributes+"]
----
NAME CSV APPROVAL APPROVED
install-shpmd metallb-operator.v4.18.0-202502261233 Automatic true
install-tsz2g metallb-operator.v{product-version}.0-202503102139 Manual false
----
. Edit the install plan that exists in the namespace by entering the following command. Ensure that you replace `<name_of_installplan>` with the name of the install plan, such as `install-tsz2g`.
+
[source,terminal]
----
$ oc edit installplan <name_of_installplan> -n metallb-system
----
+
.. With the install plan open in your editor, set the `spec.approval` parameter to `Manual` and set the `spec.approved` parameter to `true`.
+
[NOTE]
====
After you edit the install plan, the upgrade operation starts. If you enter the `oc -n metallb-system get csv` command during the upgrade operation, the output might show the `Replacing` or the `Pending` status.
====
.Verification
. Verify the upgrade was successful by entering the following command:
+
[source,terminal]
----
$ oc -n metallb-system get csv
----
+
.Example output
[source,terminal]
----
NAME DISPLAY VERSION REPLACE PHASE
metallb-operator.v4.19.0-202503102139 MetalLB Operator {product-version}.0-202503102139 metallb-operator.v4.18.0-202502261233 Succeeded
----

View File

@@ -1,56 +0,0 @@
// Module included in the following assemblies:
//
// * operators/metallb/metallb-upgrading-operator.adoc
:_mod-docs-content-type: PROCEDURE
[id="olm-deleting-metallb-operator-from-a-cluster-using-cli_{context}"]
= Deleting MetalLB Operator from a cluster using the CLI
Cluster administrators can delete installed Operators from a selected namespace by using the CLI.
.Prerequisites
- Access to an {product-title} cluster using an account with
`cluster-admin` permissions.
- `oc` command installed on workstation.
.Procedure
. Check the current version of the subscribed MetalLB Operator in the `currentCSV` field:
+
[source,terminal]
----
$ oc get subscription metallb-operator -n metallb-system -o yaml | grep currentCSV
----
+
.Example output
[source,terminal]
----
currentCSV: metallb-operator.4.10.0-202207051316
----
. Delete the subscription:
+
[source,terminal]
----
$ oc delete subscription metallb-operator -n metallb-system
----
+
.Example output
[source,terminal]
----
subscription.operators.coreos.com "metallb-operator" deleted
----
. Delete the CSV for the Operator in the target namespace using the `currentCSV` value from the previous step:
+
[source,terminal]
----
$ oc delete clusterserviceversion metallb-operator.4.10.0-202207051316 -n metallb-system
----
+
.Example output
[source,terminal]
----
clusterserviceversion.operators.coreos.com "metallb-operator.4.10.0-202207051316" deleted
----

View File

@@ -1,31 +0,0 @@
// Module included in the following assemblies:
//
// * operators/metallb/metallb-upgrading-operator.adoc
:_mod-docs-content-type: PROCEDURE
[id="olm-deleting-metallb-operator-from-a-cluster-using-web-console_{context}"]
= Deleting the MetalLB Operator from a cluster using the web console
Cluster administrators can delete installed Operators from a selected namespace by using the web console.
.Prerequisites
- Access to an {product-title} cluster web console using an account with
`cluster-admin` permissions.
.Procedure
. Navigate to the *Operators* → *Installed Operators* page.
. Search for the MetalLB Operator. Then, click on it.
. On the right side of the *Operator Details* page, select *Uninstall Operator* from the *Actions* drop-down menu.
+
An *Uninstall Operator?* dialog box is displayed.
. Select *Uninstall* to remove the Operator, Operator deployments, and pods. Following this action, the Operator stops running and no longer receives updates.
+
[NOTE]
====
This action does not remove resources managed by the Operator, including custom resource definitions (CRDs) and custom resources (CRs). Dashboards and navigation items enabled by the web console and off-cluster resources that continue to run might need manual clean up. To remove these after uninstalling the Operator, you might need to manually delete the Operator CRDs.
====

View File

@@ -27,7 +27,7 @@ In most cases, the web console method of this procedure is preferred because it
.Prerequisites
ifndef::olm-user[]
- Access to an {product-title} cluster using an account with
* Access to an {product-title} cluster using an account with
ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
`cluster-admin` permissions.
endif::[]
@@ -37,10 +37,10 @@ endif::[]
endif::[]
ifdef::olm-user[]
- Access to an {product-title} cluster using an account with Operator installation permissions.
* Access to an {product-title} cluster using an account with Operator installation permissions.
endif::[]
- You have installed the OpenShift CLI (`oc`).
* You have installed the OpenShift CLI (`oc`).
.Procedure
@@ -129,7 +129,7 @@ $ oc get packagemanifests <operator_name> -n <catalog_namespace> -o yaml
----
====
** If more than one catalog is installed in a namespace, run the following command to look up the available versions and channels of an Operator from a specific catalog:
. If more than one catalog is installed in a namespace, run the following command to look up the available versions and channels of an Operator from a specific catalog:
+
[source,terminal]
----
@@ -155,7 +155,7 @@ If the Operator you intend to install supports the `SingleNamespace` install mod
====
You can only have one Operator group per namespace. For more information, see "Operator groups".
====
+
.. Create an `OperatorGroup` object YAML file, for example `operatorgroup.yaml`, for `SingleNamespace` install mode:
+
.Example `OperatorGroup` object for `SingleNamespace` install mode
@@ -171,7 +171,7 @@ spec:
- <namespace> <1>
----
<1> For `SingleNamespace` install mode, use the same `<namespace>` value for both the `metadata.namespace` and `spec.targetNamespaces` fields.
+
.. Create the `OperatorGroup` object:
+
[source,terminal]
@@ -180,7 +180,7 @@ $ oc apply -f operatorgroup.yaml
----
. Create a `Subscription` object to subscribe a namespace to an Operator:
+
.. Create a YAML file for the `Subscription` object, for example `subscription.yaml`:
+
[NOTE]
@@ -264,9 +264,9 @@ spec:
<1> Set the approval strategy to `Manual` in case your specified version is superseded by a later version in the catalog. This plan prevents an automatic upgrade to a later version and requires manual approval before the starting CSV can complete the installation.
<2> Set a specific version of an Operator CSV.
====
+
.. For clusters on cloud providers with token authentication enabled, such as {aws-first} {sts-first}, {entra-first}, or {gcp-wid-first}, configure your `Subscription` object by following these steps:
+
... Ensure the `Subscription` object is set to manual update approvals:
+
.Example `Subscription` object with manual update approvals
@@ -281,11 +281,10 @@ spec:
----
<1> Subscriptions with automatic approvals for updates are not recommended because there might be permission changes to make before updating. Subscriptions with manual approvals for updates ensure that administrators have the opportunity to verify the permissions of the later version, take any necessary steps, and then update.
====
+
... Include the relevant cloud provider-specific fields in the `Subscription` object's `config` section:
+
--
* If the cluster is in AWS STS mode, include the following fields:
If the cluster is in AWS STS mode, include the following fields:
+
.Example `Subscription` object with {aws-short} {sts-short} variables
[%collapsible]
@@ -302,8 +301,8 @@ spec:
----
<1> Include the role ARN details.
====
* If the cluster is in {entra-short} mode, include the following fields:
+
If the cluster is in {entra-short} mode, include the following fields:
+
.Example `Subscription` object with {entra-short} variables
[%collapsible]
@@ -326,8 +325,8 @@ spec:
<2> Include the tenant ID.
<3> Include the subscription ID.
====
* If the cluster is in {gcp-wid-short} mode, include the following fields:
+
If the cluster is in {gcp-wid-short} mode, include the following fields:
+
.Example `Subscription` object with {gcp-wid-short} variables
[%collapsible]
@@ -344,9 +343,10 @@ spec:
- name: SERVICE_ACCOUNT_EMAIL
value: "<service_account_email>" <2>
----
====
+
where:
+
`<audience>`:: Created in {gcp-short} by the administrator when they set up {gcp-wid-short}, the `AUDIENCE` value must be a preformatted URL in the following format:
+
[source,text]
@@ -359,9 +359,7 @@ where:
----
<service_account_name>@<project_id>.iam.gserviceaccount.com
----
====
--
+
.. Create the `Subscription` object by running the following command:
+
[source,terminal]

View File

@@ -1,113 +0,0 @@
// Module included in the following assemblies:
//
// * operators/metallb/metallb-upgrading-operator.adoc
:_mod-docs-content-type: PROCEDURE
[id="olm-updating-metallb-operatorgroup_{context}"]
= Editing the MetalLB Operator Operator group
When upgrading from any MetalLB Operator version up to and including 4.10 to 4.11 and later, remove `spec.targetNamespaces` from the Operator group custom resource (CR). You must remove the spec regardless of whether you used the web console or the CLI to delete the MetalLB Operator.
[NOTE]
====
The MetalLB Operator version 4.11 or later only supports the `AllNamespaces` install mode, whereas 4.10 or earlier versions support `OwnNamespace` or `SingleNamespace` modes.
====
.Prerequisites
- You have access to an {product-title} cluster with `cluster-admin` permissions.
- You have installed the OpenShift CLI (`oc`).
.Procedure
. List the Operator groups in the `metallb-system` namespace by running the following command:
+
[source,terminal]
----
$ oc get operatorgroup -n metallb-system
----
+
.Example output
[source,terminal]
----
NAME AGE
metallb-system-7jc66 85m
----
. Verify that the `spec.targetNamespaces` is present in the Operator group CR associated with the `metallb-system` namespace by running the following command:
+
[source,terminal]
----
$ oc get operatorgroup metallb-system-7jc66 -n metallb-system -o yaml
----
+
.Example output
[source,terminal]
----
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
annotations:
olm.providedAPIs: ""
creationTimestamp: "2023-10-25T09:42:49Z"
generateName: metallb-system-
generation: 1
name: metallb-system-7jc66
namespace: metallb-system
resourceVersion: "25027"
uid: f5f644a0-eef8-4e31-a306-e2bbcfaffab3
spec:
targetNamespaces:
- metallb-system
upgradeStrategy: Default
status:
lastUpdated: "2023-10-25T09:42:49Z"
namespaces:
- metallb-system
----
. Edit the Operator group and remove the `targetNamespaces` and `metallb-system` present under the `spec` section by running the following command:
+
[source,terminal]
----
$ oc edit n metallb-system
----
+
.Example output
+
[source,terminal]
----
operatorgroup.operators.coreos.com/metallb-system-7jc66 edited
----
. Verify the `spec.targetNamespaces` is removed from the Operator group custom resource associated with the `metallb-system` namespace by running the following command:
+
[source,terminal]
----
$ oc get operatorgroup metallb-system-7jc66 -n metallb-system -o yaml
----
+
.Example output
[source,terminal]
----
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
annotations:
olm.providedAPIs: ""
creationTimestamp: "2023-10-25T09:42:49Z"
generateName: metallb-system-
generation: 2
name: metallb-system-7jc66
namespace: metallb-system
resourceVersion: "61658"
uid: f5f644a0-eef8-4e31-a306-e2bbcfaffab3
spec:
upgradeStrategy: Default
status:
lastUpdated: "2023-10-25T14:31:30Z"
namespaces:
- ""
----

View File

@@ -6,37 +6,16 @@ include::_attributes/common-attributes.adoc[]
toc::[]
If you are currently running version 4.10 or an earlier version of the MetalLB Operator, please note that automatic updates to any version later than 4.10 do not work. Upgrading to a newer version from any version of the MetalLB Operator that is 4.11 or later is successful. For example, upgrading from version 4.12 to version 4.13 will occur smoothly.
A `Subscription` custom resource (CR) that subscribes the namespace to `metallb-system` by default, automatically sets the `installPlanApproval` parameter to `Automatic`. This means that when Red{nbsp}Hat-provided Operator catalogs include a newer version of the MetalLB Operator, the MetalLB Operator is automatically upgraded.
A summary of the upgrade procedure for the MetalLB Operator from 4.10 and earlier is as follows:
If you need to manually control upgrading the MetalLB Operator, set the `installPlanApproval` parameter to `Manual`.
. Delete the installed MetalLB Operator version for example 4.10. Ensure that the namespace and the `metallb` custom resource are not removed.
. Using the CLI, install the MetalLB Operator {product-version} in the same namespace where the previous version of the MetalLB Operator was installed.
[NOTE]
====
This procedure does not apply to automatic z-stream updates of the MetalLB Operator, which follow the standard straightforward method.
====
For detailed steps to upgrade the MetalLB Operator from 4.10 and earlier, see the guidance that follows. As a cluster administrator, start the upgrade process by deleting the MetalLB Operator by using the OpenShift CLI (`oc`) or the web console.
//Delete metallb using web console
include::modules/olm-deleting-metallb-operators-from-a-cluster-using-web-console.adoc[leveloffset=+1]
//Delete metallb using cli
include::modules/olm-deleting-metallb-operators-from-a-cluster-using-cli.adoc[leveloffset=+1]
//Delete targetNamespace
include::modules/olm-updating-metallb-operatorgroup.adoc[leveloffset=+1]
//Upgrade the MetalLB
// Manually upgrading the MetalLB Operator
include::modules/nw-metalLB-basic-upgrade-operator.adoc[leveloffset=+1]
[id="additional-resources"]
== Additional resources
* xref:../../../operators/admin/olm-deleting-operators-from-cluster.adoc#olm-deleting-operators-from-a-cluster[Deleting Operators from a cluster]
* xref:../../../updating/understanding_updates/intro-to-updates.adoc#intro-to-updates_intro-to-updates[Introduction to OpenShift updates]
* xref:../../../networking/networking_operators/metallb-operator/metallb-operator-install.adoc#metallb-operator-install[Installing the MetalLB Operator]

View File

@@ -38,6 +38,7 @@ include::modules/olm-installing-operators-from-operatorhub.adoc[leveloffset=+1]
* xref:../../operators/understanding/olm-understanding-operatorhub.adoc#olm-understanding-operatorhub[Understanding OperatorHub]
// Installing from OperatorHub by using the CLI
include::modules/olm-installing-from-operatorhub-using-web-console.adoc[leveloffset=+1]
[role="_additional-resources"]
@@ -46,6 +47,8 @@ include::modules/olm-installing-from-operatorhub-using-web-console.adoc[leveloff
* xref:../../operators/admin/olm-upgrading-operators.adoc#olm-approving-pending-upgrade_olm-upgrading-operators[Manually approving a pending Operator update]
ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
// Installing from OperatorHub by using the CLI
include::modules/olm-installing-from-operatorhub-using-cli.adoc[leveloffset=+1]
[role="_additional-resources"]
@@ -58,7 +61,7 @@ include::modules/olm-installing-from-operatorhub-using-cli.adoc[leveloffset=+1]
include::modules/olm-preparing-multitenant-operators.adoc[leveloffset=+1]
.Next steps
* Install the Operator in the tenant Operator namespace. This task is more easily performed by using the OperatorHub in the web console instead of the CLI; for a detailed procedure, see xref:../../operators/admin/olm-adding-operators-to-cluster.adoc#olm-installing-from-operatorhub-using-web-console_olm-adding-operators-to-a-cluster[Installing from OperatorHub using the web console].
* Install the Operator in the tenant Operator namespace. This task is more easily performed by using the OperatorHub in the web console instead of the CLI; for a detailed procedure, "Installing from OperatorHub using the web console".
+
[NOTE]
====
@@ -71,9 +74,10 @@ After completing the Operator installation, the Operator resides in the tenant O
* xref:../../operators/understanding/olm-multitenancy.adoc#olm-multitenancy[Operators in multitenant clusters]
include::modules/olm-installing-global-namespaces.adoc[leveloffset=+1]
.Next steps
* Install the desired Operator in your custom global namespace. Because the web console does not populate the *Installed Namespace* menu during Operator installation with custom global namespaces, this task can only be performed with the OpenShift CLI (`oc`). For a detailed procedure, see xref:../../operators/admin/olm-adding-operators-to-cluster.adoc#olm-installing-operator-from-operatorhub-using-cli_olm-adding-operators-to-a-cluster[Installing from OperatorHub using the CLI].
* Install the desired Operator in your custom global namespace. Because the web console does not populate the *Installed Namespace* menu during Operator installation with custom global namespaces, the install task can only be performed with the OpenShift CLI (`oc`). For a detailed installation procedure, see "Installing from OperatorHub using the CLI".
+
[NOTE]
====