Can you help us understand how we can fix that? Once we know how to work around that then we will send a fix at the earliest.
Assigning this to Noah too.
It would be useful to see the output from the two tasks that run before the task whose output is in this ticket, just to rule out anything there. Those tasks would be:
- name: generate monitor initial keyring
- name: read monitor initial keyring if it already exists
Seb: In the end it looks like there is a silent error preventing the keyring from being created or from being placed into the correct location. That is handled by the `ceph_key.py` helper, but in the trace above there isn't any output that'd indicate an error or bad behavior. Is there a way to turn up logging level? I think if not, then it is going to require reproducing that locally to work through `ceph_key.py` to find the source of the issue. Does that sound plausible/reasonable?
This is probably not a ceph-ansible bug.
*** Bug 1636364 has been marked as a duplicate of this bug. ***
This is a priority for 3.2Z2. And the fix needs to merge into 4.x builds as well.
(In reply to Federico Lucifredi from comment #16)
> This is a priority for 3.2Z2. And the fix needs to merge into 4.x builds as
I have created this one for 4.0 - https://bugzilla.redhat.com/show_bug.cgi?id=1684272
Noticed the on_qa flag was set. Excellent!
Would it be beneficial to Engineering for the customer to test this in their environment prior to release? May help ensure all issues are resolved. If yes, please set needinfo to me (email@example.com) and I'll loop in the account team (Carolyn Heeley <firstname.lastname@example.org>) to figure out procedurally how to do the pre-release testing.
If not, no worries. Wanted to make the offer!
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.