Document URL: As per the bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1868287#c1 the feature mentioned here fails on IPI install. https://osdocs-1155--ocpdocs.netlify.app/openshift-enterprise/latest/networking/configuring-node-port-service-range.html https://issues.redhat.com/browse/OSDOCS-1155 The above documentation does not highlight the same, we can update the doc with the inclusion of feature with UPI clusters only. We can include a note for this feature. Test results fail on an IPI cluster, ~~~ [root@vm251-77 ~]# oc patch network.config.openshift.io cluster --type=merge -p \ > '{ > "spec": > { "serviceNodePortRange": "30000-39999" } > }' network.config.openshift.io/cluster patched [root@vm251-77 ~]# oc get configmaps -n openshift-kube-apiserver config \ > -o jsonpath="{.data['config\.yaml']}" | \ > grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]' "service-node-port-range":["30000-39999"] [root@vm251-77 ~]# oc get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ruby-ex NodePort 172.30.241.165 <none> 8080:33911/TCP 13m [root@vm251-77 ~]# oc get ep NAME ENDPOINTS AGE ruby-ex 10.129.2.217:8080 13m [root@vm251-77 ~]# oc expose svc/ruby-ex route.route.openshift.io/ruby-ex exposed [root@vm251-77 ~]# oc get route NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD ruby-ex ruby-ex-nodeporttest.apps.simore-46.indiashift.support ruby-ex 8080-tcp None [root@vm251-77 ~]# curl -kvv https://ruby-ex-nodeporttest.apps.simore-46.indiashift.support:33911 * About to connect() to ruby-ex-nodeporttest.apps.simore-46.indiashift.support port 33911 (#0) * Trying 52.66.82.23... ~~~ Section Number and Name: Describe the issue: Suggestions for improvement: Additional information:
The documentation could also include the commands to remove them if an user attempts the patch command and then wishes to take them out. Thanks.
So, I think the relationship between user-provisioned and installer-provisioned infrastructure has come up in the past, and once the cluster is installed, it is all OpenShift. There isn't supposed to be any distinction. So I don't think it is correct to say that it only works on user-provisioned infrastructure; the controlling issue is whether the expanded port range is accessible on the nodes or not. I'll replace "security groups" with terminology that is platform agnostic. Thanks!
For this feature, it is not currently possible to revert a change after it has been made, so there is no procedure for reverting.
I clarified the language regarding firewalls and packet filtering devices.