OCP/Telco Definition of Done

Epic Template descriptions and documentation.

Epic Goal

Ingress Controller's AllowedSourceRanges API field doesn't fully control the load balanacer service's spec.loadBalancerSourceRanges field. If you apply spec.endpointPublishingStrategy.loadBalancer.allowedSourceRanges on the ingress controller, then later remove it, the service's spec.loadBalancerSourceRanges doesn't get removed.

This is a known issue and is intended by the definition in the EP. This logic prevents overwriting values on the service's loadBalancerSourceRanges, which were set by the cluster admin, to maintain compatibility.

The EP describes the future work:

Based on this information, a future OpenShift release may block upgrades when .Spec.LoadBalancerSourceRanges and AllowedSourceRanges do not match, and in a release subsequent to that, AllowedSourceRanges will fully own and overwrite .Spec.LoadBalancerSourceRanges, also when it is empty.

We need to:

1. Review the evaluation condition provided by telemetry to understand how many customers may be impacted by this update
2. If appropriate, update the ingress operator to have full control of the services loadBalancerSourceRanges
3. Add a release note describing that the ingress operator will remove directly added loadBalancerSourceRanges in services.

EP Link: https://github.com/openshift/enhancements/blob/master/enhancements/ingress/lb-allowed-source-ranges.md 

EP PR Link: https://github.com/openshift/enhancements/pull/1177 

Slack Link: https://redhat-internal.slack.com/archives/CCH60A77E/p1698943648116229 

Why is this important?

• The API is confusing and customers may file bugs for it.

Drawbacks

• Some risk to removing directly specified loadBalancerSourceRanges and exposing customers Ingress Controllers to unwanted CIDRs

Scenarios

• N/A

Acceptance Criteria

• Ingress Operator has full control/reconcilation of loadBalancerSourceRanges

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions::

1. …

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub
  Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub
  Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>