Merge pull request #89609 from dfitzmau/OCPBUGS-49969

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

Author: dfitzmau

modules/nw-metalLB-basic-upgrade-operator.adoc

@@ -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
 ----

modules/olm-deleting-metallb-operators-from-a-cluster-using-cli.adoc

@@ -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]