Bug 1493268

Summary:	openshift-ansible (upgrade) should fetch the data of known config values instead of fail if not in the inventory
Product:	OpenShift Container Platform	Reporter:	Matt Woodson <mwoodson>
Component:	Cluster Version Operator	Assignee:	Andrew Butcher <abutcher>
Status:	CLOSED DUPLICATE	QA Contact:	liujia <jiajliu>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.7.0	CC:	aos-bugs, ghuang, jokerman, mmccomas, pportant, smilner
Target Milestone:	---
Target Release:	3.7.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-09-22 05:53:39 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Matt Woodson 2017-09-19 18:49:24 UTC

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.

Comment 1 Steve Milner 2017-09-19 20:40:08 UTC

> 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

Comment 2 Scott Dodson 2017-09-19 20:53:37 UTC

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.

Comment 3 Scott Dodson 2017-09-20 14:14:39 UTC

https://github.com/openshift/openshift-ansible/pull/5471 proposed quick fix to make this only required during scaleup

Comment 4 Gan Huang 2017-09-22 05:53:39 UTC

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 ***