Description of problem:

• It is apparently possible to expand nodeport range into the protected port range of 0-32767 (increase from previous cap of 30000-32767).
• There is no known way to revert this change, as you cannot reduce a nodeport range once expanded:

$ 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":["0-32767"]

If I try to siwtch it back to the default value i get

$ oc patch network.config.openshift.io cluster --type=merge -p '{
    "spec":
      { "serviceNodePortRange": "30000-32767" }
  }'

The Network "cluster" is invalid: spec.serviceNodePortRange: Invalid value: "30000-32767": new service node port range 30000-32767 does not completely cover the previous range 0-32767 

Version-Release number of selected component (if applicable):

• all current releases of openshift

How reproducible:

• every time

Steps to Reproduce:

1. see issue detail above, patch cluster and observe inability to revert change.

2.

3.

Actual results:

• cluster reversion is required, cluster port reservations are compromised.

Expected results:

• nodeport range non-reduction is not a question (though perhaps we should open an RFE for that) but this bug is to address that we should consider making it harder to set the LOWER boundary below 30000. An alert `are you sure` is advisable to avoid this problem. Filing as a bug, rather than RFE because this has a significant impact and is a costly error with no known workarounds.

Additional info:

Please fill in the following template while reporting a bug and provide as much relevant information as possible. Doing so will give us the best chance to find a prompt resolution.

Affected Platforms:

Is it an

1. internal RedHat testing failure

If it is an internal RedHat testing failure:

• Please share a kubeconfig or creds to a live cluster for the assignee to debug/troubleshoot along with reproducer steps (specially if it's a telco use case like ICNI, secondary bridges or BM+kubevirt).
• I can spin up a test cluster as needed for this but this is not platform specific and should be easily replicated without a specific build. flagging as redhat testing failure since this is something we can take steps to detect and prevent.

If we need to convert to RFE, please ensure it is given due consideration/prioritize accordingly. For production clusters this can spell a disasterous downtime event that is preventable with a confirmation.

See https://www.spinics.net/lists/ceph-devel/msg41978.html -->

ceph sync force {–yes-i-really-mean-it} {–i-know-what-i-am-doing}