Description of problem: I have a customer who needs to expand the current serviceNetworkCIDR in v3.9 as the service network is running low on the address. In the documentation, it is mentioned that it can be done considering the appropriate length. [+] https://docs.openshift.com/container-platform/3.9/install_config/configuring_sdn.html#expanding-the-service-network <snip> You can change serviceNetworkCIDR from 172.30.0.0/16 to 172.30.0.0/15, but not to 172.28.0.0/14, because even though the original range is entirely inside the new range, the original range must be at the start of the CIDR. </snip> However, the steps are not outlined anywhere and not sure how fully it is supported for production environments. Although, when we add "openshift_portal_net=172.30.0.0/15" in the host file, we have to run the playbooks/openshift-master/config.yml to get in effect with new CIDR range. Based on the document[1], changing serviceCIDR still seems not supported and recommended. There is an RFE[2] which closed as won't fix and did not receive any ack for v3.11 as well. [1] https://access.redhat.com/solutions/3515431 [Modify servicesSubnet and serviceNetworkCIDR in OpenShift ] [2] https://bugzilla.redhat.com/show_bug.cgi?id=1370295 [RFE - Changing the servicesSubnet and the serviceNetworkCIDR after installation fails] Version-Release number of selected component (if applicable): v3.9 Can we confirm the status of this feature? If the expansion in seriviceCIDR is supported in v3.9, do we have validated steps?
@Rutvik, Checking Bug 1571229 - [RFE] - Extend serviceNetworkCIDR subnet length (docs) 1.serviceNetworkCIDR can only be expanded, it can not be changed or contracted. 2.Expanding serviceNetworkCIDR is supported from v3.10 3.Steps to expand serviceNetworkCIDR is described in https://github.com/openshift/openshift-docs/blob/2bddd51657a00deb196854219f104fa73f4ce8b2/install_config/configuring_sdn.adoc
Hello Weibin, Thanks for the confirmation. In this situation, if I plan to upgrade my v3.9 environment to v3.10, I would set openshift_portal_net="172.x.x.x/y" variable in the inventory, will the upgrade playbook be able to expand the existing subnet post-upgrade? Or Do I need to upgrade first with the existing seriviceNetwork and then follow the procedure as defined here? [+] https://github.com/openshift/openshift-docs/blob/2bddd51657a00deb196854219f104fa73f4ce8b2/install_config/configuring_sdn.adoc
That's a good question for the openshift-ansible team. However, my suggestion would be to minimize risk by separating the service network change from the upgrade.
Hello, In reply to Casey Callendrello from comment #6) > Sorry, what are you asking? To expand the service network, you need to > upgrade to 3.10 > > 3.9 (and 3.10) is very close to EOL. We won't be adding any new features to > it. Because of comment #3, there was confusion. Thanks for the clarification. Few more things need clarification. Based on this document: https://docs.openshift.com/container-platform/3.10/install_config/configuring_sdn.html#expanding-the-service-network Not sure whether the node evacuation is part of "serivceexpansion" procedure or not. If we see the upstream document: https://github.com/openshift/openshift-docs/blob/enterprise-3.10/install_config/configuring_sdn.adoc#expanding-the-service-network We can see that node evacuation is not included here. If node evacuation necessary, do we need to evacuate the master nodes as well? Do we need to file any document bug here?
Hi there, Good question. Yes, the node drain is required. If master nodes are running pods, then, yes, they too need to be drained (one at a time, of course). It does seem like there is a document discrepancy. I think the "container-platform" documents are correct in this case.
OCP 3.9 has reached the end of full support [1]. Closing this BZ as WONTFIX. If there is a customer case to be attached with a valid support exception and we still need a fix here, please post those details and reopen. [1] - https://access.redhat.com/support/policy/updates/openshift