Hide Forgot
Description of problem: for now, ingress did not do validation, for example. 1. The 'host' can be exceed 63 characters 2. we can create 2 same host when doing 'oc get ing', it's showing: $ oc get ing NAME HOSTS ADDRESS PORTS AGE test 1.qwertyuioplkjhgfdsazxcvbnmlkjhgfdsaqwertyuiopmnbvcxzasqwertingress-test.com 80 23m test-ingress foo.bar.com 80 16m test1-ingress foo.bar.com but it's mapping routes will be marked as $ oc get route NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD test-ingress-8dzft foo.bar.com service-unsecure 8080 None test-smjwp InvalidHost /test service-unsecure 8080 None test1-ingress-tqw2m HostAlreadyClaimed service-unsecure 8080 None so should add related validation in ingress side also. otherwise, if the ingress can be shown correctly for user, but in fact it cannot be used. Version-Release number of selected component (if applicable): v3.10.0-0.16.0 How reproducible: always Steps to Reproduce: 1. Create ingress with 'host' exceed 63 characters 2. Create two ingresses with same 'host' 3. check the ingress oc get ing Actual results: As $Description Expected results: step 3 the 'host' should show same as `oc get route` Additional info:
Quick update here: the IngressRule host length validation issue needs to be verified and an issue filed upstream to fix validation at the API level. The host field is specified as a DNS-1123 subdomain. Regarding the duplicate Ingress hosts: k8s Ingress doesn't have a claim mechanism[1], so technically the two Ingress resources are valid in k8s by design; how an ingress controller (e.g. the OpenShift router) should react to this state is unspecified. In practice, it looks like the OpenShift router does something reasonable (grants a claim to the oldest Ingress). So in that regard, I think the only issue with the OpenShift router is a documentation gap: we should describe our ingress controller's behavior in this case when acting as a k8s ingress controller. [1] https://github.com/kubernetes/kubernetes/issues/30151
Upon further review, RFC[1] states: Host software MUST handle host names of up to 63 characters and SHOULD handle host names of up to 255 characters. Kube seems to conform in this regard[2]. [1] https://tools.ietf.org/html/rfc1123#section-2.1 [2] https://github.com/kubernetes/apimachinery/blob/master/pkg/util/validation/validation.go#L128
Upon further further review, The Ingress resource validation seems to be correct in terms of its stated type (an RFC1123 hostname), but the question remains as to whether it should be something like a DNS FQDN (whereby each subdomain segment would be validated as a DNS label). The OpenShift Route is ultimately rejecting the name as an invalid FQDN, but the unaccepted Route status isn't reflected back into the Ingress status. It's not clear that the "valid" Ingress would actually be usable in terms of DNS. We should engage upstream about the field to clarify the meaning of the IngressRule.Host field. In the meantime, given the impedance mismatch between Route and Ingress in this regard, perhaps confusion could be minimized by reflecting the invalid Route status back to the Ingress status so it's at least clear that the Ingress is not being fulfilled.
Given the severity of this report we don't believe we'll be able to prioritize this issue in the short or medium term. We apologize that we are going to close the bug as WONTFIX.