@anbhat @ccallend In v4.1, we do not support externalIP: policy: {}, here is the log from "oc edit networks.config.openshift.io cluster" in both v4.1 and v4.3, spec: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 networkType: OpenShiftSDN serviceNetwork: - 172.30.0.0/16 #### v4.3 support externalIP: policy: {} spec: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 externalIP: >>>>>>>>>>>>>> v4.1 do not have this policy: {} >>>>>>>>>>>>>> networkType: OpenShiftSDN serviceNetwork: - 172.30.0.0/16 Look like I can not verify this bug in v4.1
Check the CRD of 4.1, it did not supported the externalIP yet. # oc get crd networks.config.openshift.io -o yaml | grep -i external for 4.2 and after version # oc get crd networks.config.openshift.io -o yaml | grep -i external -A 10 externalIP: description: externalIP defines configuration for controllers that affect Service.ExternalIP. If nil, then ExternalIP is not allowed to be set. properties: autoAssignCIDRs: description: autoAssignCIDRs is a list of CIDRs from which to automatically assign Service.ExternalIP. These are assigned when the service is of type LoadBalancer. In general, this is only useful for bare-metal clusters. In Openshift 3.x, this was misleadingly called "IngressIPs". Automatically assigned External IPs are not affected by any ExternalIPPolicy rules. Currently, only one entry may be provided. items: type: string type: array policy: description: policy is a set of restrictions applied to the ExternalIP field. If nil or empty, then ExternalIP is not allowed to be set. properties: allowedCIDRs: description: allowedCIDRs is the list of allowed CIDRs. items: type: string type: array rejectedCIDRs: description: rejectedCIDRs is the list of disallowed CIDRs. These take precedence over allowedCIDRs.
Zhanqi, You are right, I still see https://bugzilla.redhat.com/show_bug.cgi?id=1751840 in latest v4.1 code. Wait the new PR for https://bugzilla.redhat.com/show_bug.cgi?id=1751840, then QE can verify this bug.
bug 1758140 and this one are essentially the same bug. If a normal user can create a service with an ExternalIP in a build of 4.1 that includes origin #23826, then that means this bug has FailedQE
Verifying failed in 4.1.0-0.nightly-2020-01-06-225053 [root@dhcp-41-193 FILE]# oc login -u testuser-0 -p gPb_u0NtGup- Login successful. You don't have any projects. You can try to create a new project, by running oc new-project <projectname> [root@dhcp-41-193 FILE]# oc new-project test Now using project "test" on server "https://api.qe-weliang-aws41.qe.devcluster.openshift.com:6443". You can add applications to this project with the 'new-app' command. For example, try: oc new-app django-psql-example to build a new example application in Python. Or use kubectl to deploy a simple Kubernetes application: kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node [root@dhcp-41-193 FILE]# oc create -f https://raw.githubusercontent.com/weliang1/Openshift_Networking/master/Features/PublishingServices/external-ip.yaml service/hello-service1 created pod/hello-pod-1 created [root@dhcp-41-193 FILE]# oc get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE hello-service1 ClusterIP 172.30.35.171 10.0.76.163 27018/TCP 4s [root@dhcp-41-193 FILE]#
4.1 EOL is imminent and it does not make sense to fix this at this point in the lifecycle.