// Modules included in the following assemblies:
//
// * ingress/configure-ingress-operator.adoc

:_mod-docs-content-type: PROCEDURE
[id="nw-ingress-setting-update-subnet-Loadbalancerservice_{context}"]
= Updating the subnets on an existing Ingress Controller

[role="_abstract"]
You can update an `IngressController` with manually specified load balancer subnets in {product-title} to avoid any disruptions, to maintain the stability of your services, and to ensure that your network configuration aligns with your specific requirements. 

The example in the procedure shows you how to select and apply new subnets, verify the configuration changes, and confirm successful load balancer provisioning. 

[WARNING]
====
This procedure may cause an outage that can last several minutes due to new DNS records propagation, new load balancers provisioning, and other factors. IP addresses and canonical names of the Ingress Controller load balancer might change after applying this procedure.
====

.Procedure

. Modify the existing IngressController by specifying the new subnets:
+
[source,yaml]
----
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name:  <name>
  namespace: openshift-ingress-operator
spec:
  domain: <domain>
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: External
      providerParameters:
        type: AWS
        aws:
          type: Classic
          classicLoadBalancer:
            subnets:
              ids:
              - <updated_subnet>
              - <updated_subnet>
              - <updated_subnet>
# ...
----
+
where:
+
`<name>`:: Specifies a name for the `IngressController`.
`<domain>`:: Specifies the DNS name serviced by the `IngressController`.
`type`:: Specifies the updated subnet IDs (or names if you using `names`).
`classicLoadBalancer`:: You can also use the `networkLoadBalancer` field if using an NLB.
`ids`:: Specifies the subnet by name using the `names` field instead of specifying the subnet by ID. This parameter is optional.
`<updated_subnet>`:: Specifies the updated subnet IDs (or names if you are using `names`).
+
[IMPORTANT]
====
You can specify a maximum of one subnet per availability zone. Only provide public subnets for external Ingress Controllers and private subnets for internal Ingress Controllers.
====

. Examine the `Progressing` condition on the `IngressController` for instructions on how to apply the subnet updates by running the following command:
+
[source,terminal]
----
$ oc get ingresscontroller -n openshift-ingress-operator subnets -o jsonpath="{.status.conditions[?(@.type==\"Progressing\")]}" | yq -PC
----
+
.Example output
[source,terminal]
----
lastTransitionTime: "2024-11-25T20:19:31Z"
message: 'One or more status conditions indicate progressing: LoadBalancerProgressing=True (OperandsProgressing: One or more managed resources are progressing: The IngressController subnets were changed from [...] to [...].  To effectuate this change, you must delete the service: `oc -n openshift-ingress delete svc/router-<name>`; the service load-balancer will then be deprovisioned and a new one created. This will most likely cause the new load-balancer to have a different host name and IP address and cause disruption. To return to the previous state, you can revert the change to the IngressController: [...]'
reason: IngressControllerProgressing
status: "True"
type: Progressing
----

. To apply the update, delete the service associated with the Ingress controller by running the following command:
+
[source,terminal]
----
$ oc -n openshift-ingress delete svc/router-<name>
----

.Verification

* To confirm that the load balancer was provisioned successfully, check the `IngressController` conditions by running the following command:
+
[source,terminal]
----  
$ oc get ingresscontroller -n openshift-ingress-operator <name> -o jsonpath="{.status.conditions}" | yq -PC
----