-
Bug
-
Resolution: Not a Bug
-
Major
-
None
-
None
-
None
-
False
-
None
-
False
-
Hypershift Sprint 18
-
0
-
0
-
0
Today the HyperShift operator uses the "PrivateStrategyType" for a "Private" value of "AWSEndpointAccessType", and it will use the "LoadBalancerServiceStrategyType" for any other value ("Public" or "PublicAndPrivate"). That's based on my understanding of https://github.com/openshift/hypershift/blob/main/control-plane-operator/hostedclusterconfigoperator/controllers/resources/ingress/reconcile.go#[…]9
Looking at the definition for "PrivateStrategyType" in https://github.com/openshift/hypershift/blob/main/vendor/github.com/openshift/api/operator/v1/types_ingress.go#L697-L703, it would appear that there is no published Ingress Controller, which isn't the expected behavior (it doesn't match our current ROSA behavior, and I feel like it would be surprising behavior even for OCP customers).
The default behavior for Ingress Controller on OCP (AWS) is "LoadBalancerService (with External scope)": https://docs.openshift.com/container-platform/4.11/networking/ingress-operator.html#nw-ingress-controller-configur[…]-parameters_configuring-ingress. This is inline with the default behavior for HyperShift (deploy LoadBalancerService with External scope).
However, the private behavior for HyperShift (deploying cluster-only access for the Ingress Controller) isn't in line with the private behavior for ROSA/OCP. OCP has the loadBalancer.scope configuration option for LoadBalancerService: https://docs.openshift.com/container-platform/4.11/networking/ingress-operator.html#nw-ingress-setting-internal-lb_configuring-ingress.
The/my expected behavior (both on what we do today on ROSA, and what I suspect would be expected in OCP) would for "Private" values of "AWSEndpointAccessType" to still deploy a "LoadBalancerServiceStrategyType" with an additional configuration setting "loadBalancer.scope" to "Internal". This still deploys the Ingress Controller with a configured Load Balancer, but the Load Balancer is deployed in the private subnet, doesn't require any additional networking, and still allows for accessing the Ingress Controller from outside the cluster (but still requiring access to the cluster's private network)
- is related to
-
HOSTEDCP-556 Reconcile Private and PublicAndPrivate changes to AWSEndpointAccessType for deployed clusters
- Closed