Bug 1417525 - Using openshift_hosted_logging_deploy=true fails on repeated runs
Summary: Using openshift_hosted_logging_deploy=true fails on repeated runs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Installer
Version: 3.4.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: ewolinet
QA Contact: Xia Zhao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-30 05:27 UTC by Peter Larsen
Modified: 2017-07-24 14:11 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: Rerunning the installation playbook with 'openshift_hosted_logging_deploy=true' would redeploy the logging deployer pod using the install mode and would fail because logging was already installed. Consequence: The ansible playbook fails due to waiting on the deployer pod to complete successfully. Fix: With 3.5 we no longer use the logging deployer pod to install logging but rather the openshift_logging role. It is able to handle previously installed logging. Result: The playbook will complete successfully
Clone Of:
Environment:
Last Closed: 2017-04-12 18:49:20 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:0903 0 normal SHIPPED_LIVE OpenShift Container Platform atomic-openshift-utils bug fix and enhancement 2017-04-12 22:45:42 UTC

Description Peter Larsen 2017-01-30 05:27:21 UTC 
Description of problem:
When setting openshift_hosted_logging_deploy=true on a deployment, re-running the config.yaml playbook will fail the deployment as existing objects are found which blocks the deployer from running. As a result, ansible times out and errors out. 


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

3.4 - pretty sure this applies to prior versions too. 

Steps to Reproduce:
1. Do default install with openshift_hosted_logging_deploy=true
2. After successful run where logging was attempted, re-run the install with the same configuration parameters.

Actual results:
Install failure


Expected results:
Logging configuration wiped out, replaced/reinstalled from scratch.
Comment 2 ewolinet 2017-01-30 15:37:55 UTC 
Can you provide the errors that are seen? Can you also please attach the logs from the Deployer pod?
Comment 3 Peter Larsen 2017-01-30 15:53:28 UTC 
(In reply to ewolinet from comment #2)
> Can you provide the errors that are seen? Can you also please attach the
> logs from the Deployer pod?

It's the same error you get when you attempt to run the logging deployer after having run the deployer before. It errors out saying templates already exist, or service accounts already exists etc. Depending on where in the process it was. There are options on the deployer template to "redeploy" and avoid these kinds of errors - I don't know if that is the right strategy for the ansible installer though.
Comment 4 ewolinet 2017-01-30 20:38:27 UTC 
Yeah, I'm not sure if using the 'redeploy' mode is the correct approach to avoid those errors... 

As stated above, with the rewrite for 3.5 we no longer rely on the deployer pod, so we should better handle cases where objects already exist without needing to remove and then reinstall.
Comment 6 Xia Zhao 2017-02-17 09:06:02 UTC 
Tested logging 3.5.0 deployment with the latest codes from https://github.com/openshift/openshift-ansible -b master, re-run playbooks succeeded, did not encounter error. Logging can be deployed successfully. Set to verified.
Comment 8 errata-xmlrpc 2017-04-12 18:49:20 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://access.redhat.com/errata/RHBA-2017:0903
Note You need to log in before you can comment on or make changes to this bug.