Background
Router Sharding is the practice of isolating DMZ traffic routes of their applications, from the internal traffic application routes. In OCP 4.X the Openshift Ingress Operator (OIO) was introduced as tooling to do this in an automated way. The OIO functions by configuring a resource called an Ingress Controller that routes traffic for OpenShift routes, and kubernetes ingresses. There are various ways that an ingress controller can route traffic in the underlying cluster. If you want to leverage a LBAAS or Load balancer in the underlying cloud, you have to specify the LoadBalancer Endpoint Publishing Strategy. To do this, it creates a Service Type LB in kubernetes, using that existing tooling to create resources in the underlying cloud.

Goals
Support Router Sharding with the OIO using LoadBalancer Endpoint Publishing Strategy when Octavia Amphora or OVN is the Service Type LB provider.

Support Default Publishing Strategy LoadBalancer with OIO when Octavia Amphora or OVN is the Service Type LB provider.

Summary
Theoretically, this should be supported by default once Octavia is fully supported as a Service Type LB provider. However, it is important that we validate this use case, and update all documentation to educate users on how to use this feature with Octavia on OpenStack.

Definition of Done

• OIO Ingress Controller can be created with publishing strategy LoadBalancer and creates Octavia LB
• Apps can leverage Router Sharding using Octavia LB using a comparable user experience to other cloud platforms
• Defining a test plan with QE
• Verification with QE
• Documentation similar to https://docs.openshift.com/container-platform/4.7/networking/load-balancing-openstack.html for non-kuryr Shift on Stack usage