Bug 1054441

Summary: oo-accept-node should test that BROKER_HOST is consistent
Product: OpenShift Container Platform Reporter: Luke Meyer <lmeyer>
Component: ContainersAssignee: Vu Dinh <vdinh>
Status: CLOSED ERRATA QA Contact: libra bugs <libra-bugs>
Severity: low Docs Contact:
Priority: low    
Version: 2.0.0CC: adellape, jdetiber, jialiu, libra-onpremise-devel, tiwillia, vdinh
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openshift-origin-broker-util-1.37.4.1-1.el6op Doc Type: Bug Fix
Doc Text:
When the BROKER_HOST parameter in the /etc/openshift/node.conf file and OPENSHIFT_BROKER_HOST environment variables are inconsistent, some cartridges, such as Jenkins, fail to work as they use those variables. The same is true for CLOUD_DOMAIN variables. This bug fix adds a warning to the `oo-accept-node` command to notify administrators to fix such inconsistencies. As a result, a warning is now issued if these variables do not match.
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-17 17:08:54 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 Luke Meyer 2014-01-16 20:33:35 UTC
Description of problem:
On a node host, the broker host configured in these two locations should be the same:
/etc/openshift/node.conf:BROKER_HOST
/etc/openshift/env/OPENSHIFT_BROKER_HOST
Same for CLOUD_DOMAIN.
Jenkins cart uses the variables from env, but nothing else AFAICS.
oo-accept-node should test for this for as long as something is using both.

Steps to Reproduce:
1. Install OSE 2.0
2. Change /etc/openshift/env/OPENSHIFT_BROKER_HOST to something bogus
3. Run oo-accept-node

Expected results:
Should complain that these values don't match.

Comment 2 Jason DeTiberus 2014-01-16 20:46:44 UTC
Is a check in oo-accept-node sufficient, or should we actually set the values in /etc/openshift/env to match the node.conf values when starting mcollective on the nodes?

Comment 3 Luke Meyer 2014-01-20 16:26:01 UTC
If you ask me, we should modify Jenkins not to be the only user of obscure settings.

But to answer directly, having mcollective set conf values at start seems a bit outside its intended purpose. I think I'd rather just have oo-accept-node report on it.

Comment 4 Luke Meyer 2014-01-20 17:24:17 UTC
Side note: when oo-diagnostics checks for SSL cert problems, it should probably also check that contacting OPENSHIFT_BROKER_HOST gets a matching cert (could be a LB URL serving up different cert from broker), since I suspect Jenkins java client will refuse to connect otherwise.

Comment 5 Vu Dinh 2015-10-15 20:43:44 UTC
In oo-diagnostics, there is a method named 'test_node_env_vars_match' that is checking to see if BROKER_HOST and CLOUD_DOMAIN are consistent with node.conf variables. So, there is no need to add similar functionality to oo-accept-node which is run by oo-diagnostics.

The PR <https://github.com/openshift/origin-server/pull/6275> is submitted to fix the SSL cert issue that is mentioned above in comment #4.

Comment 9 Johnny Liu 2015-11-13 06:19:21 UTC
Verified this bug with rubygem-openshift-origin-common-1.29.4.1-1.el6op.noarch, and PASS.

When the value of BROKER_HOST is different on a node between the `/etc/openshift/node.conf` file and the `/etc/openshift/env/OPENSHIFT_BROKER_HOST` environment variable file, oo-diagnostics reports an WARNNING about the inconsistency



# oo-diagnostics 
<--snip-->
INFO: running: test_node_env_vars_match
WARN: block in test_node_env_vars_match
          /etc/openshift/env/OPENSHIFT_BROKER_HOST contains 'broker.ose22-auto.com.cn'
          /etc/openshift/node.conf:BROKER_HOST specifies 'node2.ose22-auto.com.cn'
          These should match; an incorrect value in either case could
          cause problems. node.conf values are used in defining application
          DNS records and proxy routing, while env var files are used for
          contacting the broker for application management actions.
<--snip-->

Comment 11 errata-xmlrpc 2015-12-17 17:08:54 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-2666.html