Add auto-delete to IngressController Subnet Selection

Add ingress.operator.openshift.io/auto-delete-load-balancer
functionality to the lb-subnet-selection-aws.md enhancement.
This allows for configuration management tooling to seamlessly update
subnets on an IngressController.

enhancements/ingress/lb-subnet-selection-aws.md

@@ -245,6 +245,15 @@ deletion will effectuate these changes.
 See [CCM Doesn't Reconcile NLB Subnets Updates](#ccm-doesnt-reconcile-nlb-subnets-updates)
 for more details on why the CCM doesn't reconcile these updates.
 
+##### Auto Effectuation with auto-delete-load-balance Annotation
+
+In addition to deleting the IngressController explicitly, it is possible to use the existing
+`ingress.operator.openshift.io/auto-delete-load-balancer` annotation to instruct the Ingress Operator to automatically
+delete the service after a subnet update. While this annotation was initially introduced to enable automatic scope
+changes in [Ingress Mutable Publishing Scope](/enhancements/ingress/mutable-publishing-scope.md), we've chosen to extend
+its usage to support the `Subnets` fields. The auto-delete annotation is not intended for end-users to use directly, but
+instead for configuration management tooling.
+
 ### Implementation Details/Notes/Constraints
 
 When an IngressController is created with
@@ -262,6 +271,10 @@ When the Ingress Operator recreates the LoadBalancer-type service, it will
 then configure `service.beta.kubernetes.io/aws-load-balancer-subnets` with
 the new `Subnets` value.
 
+The only exception is if the `ingress.operator.openshift.io/auto-delete-load-balancer`
+annotation is set on the IngressController, in which case the operator automatically deletes
+the service and effectuates the subnet update.
+
 The `status.endpointPublishingStrategy.loadBalancer.providerParameters.aws.subnets`
 will eventually reflect the configured subnet value by mirroring the value of
 `service.beta.kubernetes.io/aws-load-balancer-subnets` on the service. There are
@@ -310,6 +323,19 @@ to be deleted and is disruptive:
    service, thus creating the load balancer with the desired subnets specified by the
    cluster admin.
 
+#### Automatically Updating an existing IngressController with new Subnets Workflow
+
+A cluster admin can add the `ingress.operator.openshift.io/auto-delete-load-balancer`
+annotation to update the subnets without requiring them to manually delete the service:
+
+1. A cluster admin adds the `ingress.operator.openshift.io/auto-delete-load-balancer`
+   annotation to the IngressController.
+2. A cluster admin edits the IngressController's
+   `spec.endpointPublishingStrategy.loadBalancer.providerParameters.aws.subnets` field.
+3. The Ingress Operator automatically deletes and recreates the LoadBalancer-type service
+   with `service.beta.kubernetes.io/aws-load-balancer-subnets` configured, thus creating
+   the load balancer with the desired subnets specified by the cluster admin.
+
 #### Unmanaged Subnet Annotation Migration Workflow
 
 Migrating an unmanaged `service.beta.kubernetes.io/aws-load-balancer-subnets`
@@ -455,6 +481,10 @@ E2E tests will cover the following scenarios:
   LoadBalancer-type service and setting `Subnets` on the IngressController while observing
   `LoadBalancerProgressing` transitioning back to `Status: False` (as described in
   [Unmanaged Subnet Annotation Migration Workflow](#unmanaged-subnet-annotation-migration-workflow)).
+- Creating a IngressController with the `ingress.operator.openshift.io/auto-delete-load-balancer`
+  annotation, updating an IngressController with new `Subnets`, and observing the service
+  get automatically deleted and recreated with `service.beta.kubernetes.io/aws-load-balancer-subnets`
+  configured to the new `Subnets`.
 
 ## Graduation Criteria