Skip to content

OCPBUGS-49969: Removed 4.10 and 4.11 references from MetalLB docs #89609

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 16, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
75 changes: 57 additions & 18 deletions modules/nw-metalLB-basic-upgrade-operator.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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
$ oc -n metallb-system get subscription metallb-operator -o yaml
----

. Edit the `Subscription` CR by setting the `installPlanApproval` parameter to `Manual`:
+
.Example output
[source,terminal]
[source,yaml]
----
metallb-system Active 31m
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
# ...
----

. Verify the `metallb` custom resource still exists:
. Find the latest {product-title} {product-version} version of the MetalLB Operator by entering the following command:
+
[source,terminal]
----
$ oc get metallb -n metallb-system
$ oc -n metallb-system get csv
----
+
.Example output
[source,terminal,subs="attributes+"]
----
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]
----
NAME AGE
metallb 33m
$ 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
----

. Follow the guidance in "Installing from OperatorHub using the CLI" to install the latest {product-version} version of the MetalLB Operator.
. 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]
====
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.
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.
====

. Verify the upgraded version of the Operator is now the {product-version} version.
.Verification

. Verify the upgrade was successful 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+"]
[source,terminal]
----
NAME DISPLAY VERSION REPLACES PHASE
metallb-operator.{product-version}.0-202207051316 MetalLB Operator {product-version}.0-202207051316 Succeeded
NAME DISPLAY VERSION REPLACE PHASE
metallb-operator.v4.19.0-202503102139 MetalLB Operator {product-version}.0-202503102139 metallb-operator.v4.18.0-202502261233 Succeeded
----

This file was deleted.

This file was deleted.

40 changes: 19 additions & 21 deletions modules/olm-installing-from-operatorhub-using-cli.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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::[]
Expand All @@ -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

Expand Down Expand Up @@ -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]
----
Expand All @@ -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
Expand All @@ -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]
Expand All @@ -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]
Expand Down Expand Up @@ -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
Expand All @@ -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]
Expand All @@ -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]
Expand All @@ -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]
Expand All @@ -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]
Expand All @@ -359,9 +359,7 @@ where:
----
<service_account_name>@<project_id>.iam.gserviceaccount.com
----
====
--

+
.. Create the `Subscription` object by running the following command:
+
[source,terminal]
Expand Down
Loading