Uploaded image for project: 'OpenShift Request For Enhancement'
  1. OpenShift Request For Enhancement
  2. RFE-3405

[RFE] - Change clusterNetwork/serviceNetwork after installation

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Done
    • Icon: Undefined Undefined
    • openshift-4.17
    • None
    • SDN
    • None
    • False
    • None
    • False
    • Not Selected

      Opening an RFE only because I don't see another with similar title and closure code. I understand that presently, the only way to modify these values is a full cluster reinstallation, and I also see that there is an existing RFE for EXPANSION of the cluster/serviceNetworks that is slated for upstream 4.12+ and in accepted status. 

      I am interested in the possibility of CHANGING the subnet entirely from an exotic range to an IANA reserved subnet after cluster comes online. 

       

      Primarily, we run into issues periodically with customers who have selected subnets that are exotic/non-standard and for various reasons, run into a work stoppage due to the fact that the subnet is conflicting with a hardcoded expected value (ovn for example rejects 254.0.0.0/16 subnet but SDN doesn't mind it) Customers periodically will ask about how they can update this value and the answer is invariably "you cannot, you must reinstall the cluster"

       

      Therefore, I am asking: can this feature be integrated or is there a core reason why this cannot be handled (I am aware that presumably the only way to accomplish this would effectively be a redeployment of crio and all active services at once) but the value here would be highly useful to our users not having to destroy an otherwise functional cluster to move subnets. Most notable example: DataGrid requires the use of IANA reserved subnets to function. Selecting outside of these class values will result in a non-functional operator/other issues.

       
      Class A: 10.0.0.0/8 (10.0.0.0 to 10.255.255.255)
      Class B: 172.16.0.0/12 (172.16.0.0 to 172.31.255.255)
      Class C: 192.168.0.0/16 (192.168.0.0 to 192.168.255.255)
      Class E: 240.0.0.0/4 (240.0.0.0 to 255.255.255.255)
       

      As we often have issues with unhappy users having to redeploy, we need a way to either: A) update the subnets without destroying cluster, or B) easily alert customers during install that they have selected an exotic range that may cause issues "are you sure you wish to proceed Y/n"

       

      I have also submitted a docs bug for increasing verbosity about these values being immutable post installation but wanted to also submit an RFE to see whether or not it was even feasible to discuss integrating this option at all. 

       

      Many customers run into this, and when the only solution is this heavily invasive...

       

      Thanks in advance for your time/thoughts/consideration.

            ddharwar@redhat.com Deepthi Dharwar
            rhn-support-wrussell Will Russell
            Votes:
            9 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated:
              Resolved: