Description of problem: I believe this is introduced in https://bugzilla.redhat.com/show_bug.cgi?id=1451023 In doing an upgrade to 3.7, I am presented with this error message: ======================================================================= osm_cluster_network_cidr, osm_host_subnet_length, and openshift_portal_net are required inventory variables when upgrading. These variables should match what is currently used in the cluster. If you don't remember what these values are you can find them in /etc/origin/master/master-config.yaml on a master with the names clusterNetworkCIDR (osm_cluster_network_cidr), hostSubnetLength (osm_host_subnet_length), and serviceNetworkCIDR (openshift_portal_net). ======================================================================= The error is saying that the vars are not in the inventory, so it can not continue. The error message continues to tell the user where they can find these variables. If config options are in the running version of Openshift, the upgrader should not ask the user to re-define them. The upgrader should go out and find the values needed from the running version and use them. The single source of truth is the running version of Openshift. I see disadvantages of trying to use a the non-running version to be the source of truth: If things are different from running config vs what is in the inventory, what is the single source of truth? If the upgrader is going to check for the values to compare, we would already have the values and then they would not need to be added. If it doesn't check, is it going to update/break the cluster with different/wrong values? I think that only options that will change or could be different should be required for an upgrade. All other info should come from the running Openshift cluster.
> If things are different from running config vs what is in the inventory, what is the single source of truth? That's exactly the problem. I believe the inventory should be the source of truth as it is what will be used to maintain the cluster over it's life. Since the value was not required previously people didn't realize how important those values were until their upgrades/scale ups didn't work. However, the fix was to help people get past a bug. I'm not against someone making this much more intelligent so that: 1. On install it requires the variables and gives an intelligent error if they are not present. 2. On upgrade or scale up it will - Run openshift facts on a master and slurp up the master config file - Pull the 3 variables out and set them internal to the installer - Fail if the inventory doesn't match what's in the master configs or - Update the master configs and bounce if the inventory doesn't match master configs
Had some follow up offline discussions. Since this default changed long ago, I believe in 3.4 upgrade we'll go ahead and ensure that this check only happens during scaleup. That's a one liner simple fix that we'll merge ASAP. Then, either this sprint or next we'll follow up with scraping the value from the first master on scaleup and remove the check. Ideally this will land before 3.7 but if it doesn't the number of clusters impacted will be limited to those who are performing a scaleup so it should be pretty low.
https://github.com/openshift/openshift-ansible/pull/5471 proposed quick fix to make this only required during scaleup
This is exactly fixing the same issue as https://bugzilla.redhat.com/show_bug.cgi?id=1451023 Closing this one, and move the verification work to https://bugzilla.redhat.com/show_bug.cgi?id=1451023 *** This bug has been marked as a duplicate of bug 1451023 ***