Bug 1421021

Summary:	If you don't want ops stack, there's a bug that route and service still get created (even if you don't mention the URL's). So if you want second ops stack, you need to do enable-ops=true.
Product:	OpenShift Container Platform	Reporter:	Miheer Salunke <misalunk>
Component:	Logging	Assignee:	Jeff Cantrill <jcantril>
Status:	CLOSED WONTFIX	QA Contact:	Xia Zhao <xiazhao>
Severity:	low	Docs Contact:
Priority:	medium
Version:	3.4.0	CC:	aos-bugs, misalunk, pweil, stwalter
Target Milestone:	---	Keywords:	Reopened
Target Release:	---	Flags:	stwalter: needinfo- stwalter: needinfo-
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-03-13 14:22:18 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 Miheer Salunke 2017-02-10 06:42:17 UTC

Description of problem:

If you don't want ops stack, the route and service still get created (even if you don't mention the URL's and even when enable-ops-cluster=false was passed in the config map. ). 

So if you want ops stack, you need to do enable-ops=true. But, enable-ops=false doesn't help if I don't want the ops' cluster.

In all, when I don't specify the kibana-ops domains, service + route still get created (but to example.com) even when enable-ops-cluster=false was passed in the config map. 

Version-Release number of selected component (if applicable):
3.4.0

How reproducible:
Always

Steps to Reproduce:
1.Don't add the KIBANA_OPS_HOSTNAME
2.Pass --from-literal enable-ops-cluster=false in the "oc create configmap logging-deployer "
3.Start the deployer

Actual results:


Expected results:


Additional info:

Comment 1 Jeff Cantrill 2017-02-10 16:26:21 UTC

This has been corrected in the 3.5 release with the move to ansible.  Closing as it is a duplicate of the referenced issue and we are unlikely to fix in the 3.2 code stream

*** This bug has been marked as a duplicate of bug 1419987 ***

Comment 2 Steven Walter 2017-02-10 22:36:32 UTC

Hi, apologies for opening a closed bug, but while the bug is mistakenly marked as 3.2, in the description it is 3.4 and the bug is attached to an urgent (sev1) case. Is there possibility of backport to 3.4 from 3.5?

Comment 5 Jeff Cantrill 2017-03-03 13:35:06 UTC

@Miheer please clarify based on #4