Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

This project is now read‑only. Starting Monday, February 2, please use https://ibm-ceph.atlassian.net/ for all bug tracking management.

Bug 1794111

Summary:	[ceph-ansible] : mon configuration failing at handler to unset noup flag causing failure of playbook
Product:	[Red Hat Storage] Red Hat Ceph Storage	Reporter:	Vasishta <vashastr>
Component:	Ceph-Ansible	Assignee:	Vasishta <vashastr>
Status:	CLOSED DUPLICATE	QA Contact:	Vasishta <vashastr>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	4.0	CC:	aschoen, ceph-eng-bugs, gabrioux, gmeno, nthomas, ykaul
Target Milestone:	rc
Target Release:	4.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:	2020-01-22 16:59:56 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 Vasishta 2020-01-22 16:56:00 UTC

Description of problem:
When site-docker.yml and add-mon.yml playbooks were initiated playbooks failed saying monitor container not found
It appeared that the playbook is expecting all mon containers on monitor node present in https://github.com/ceph/ceph-ansible/blob/stable-4.0/roles/ceph-handler/tasks/handler_osds.yml#L6-L10

Version-Release number of selected component (if applicable):
# rpm -qa|grep ceph-ansible
ceph-ansible-4.0.10-1.el7cp.noarch


How reproducible:
Always (2/2)

Steps to Reproduce:
1. configure containerized 4.x cluster

Actual results:
Playbook is failing looking for containers in inappropriate nodes

Expected results:
Playbooks must not fail

Additional info:

Workaround : Ignore errors and Restart site-docker if needed

Target release has been set tentatively based on impact on usability criteria, please feel free to re-target if its inappropriately

Comment 2 Guillaume Abrioux 2020-01-22 16:59:56 UTC


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