Bug 1537390

Summary: [cephmetrics] Installation of cephmetrics with non-default password fails
Product: [Red Hat Storage] Red Hat Ceph Storage Reporter: Madhavi Kasturi <mkasturi>
Component: Ceph-MetricsAssignee: Boris Ranto <branto>
Status: CLOSED ERRATA QA Contact: Pratik Surve <prsurve>
Severity: high Docs Contact: Aron Gunn <agunn>
Priority: high    
Version: 2.5CC: agunn, anharris, branto, ceph-eng-bugs, gmeno, hnallurv, jbrier, kdreyer
Target Milestone: rc   
Target Release: 3.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: cephmetrics-ansible-2.0-1.el7cp Doc Type: Bug Fix
Doc Text:
.Installation of {product} Dashboard with a non-default password no longer fails Previously, the Red Hat Storage Dashboard (cephmetrics) could only be deployed with the default password. To use a different password it had to be changed in the Web UI afterwards. With this update to {product} you can now set the Red Hat Ceph Storage Dashboard admin username and password using Ansible variables `grafana.admin_user` and `grafana.admin_password`. For an example of how to set these variables, see the `group_vars/all.yml.sample` file.
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-09-26 18:18:23 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:
Bug Depends On:    
Bug Blocks: 1536401, 1584264    
Attachments:
Description Flags
playbook.log none

Description Madhavi Kasturi 2018-01-23 05:37:55 UTC
Created attachment 1384680 [details]
playbook.log

Description of problem:
cephmetrics-ansible installation with non-default password using vars.yml fails.

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

[root@magna024 cephmetrics-ansible]# ceph -v
ceph version 10.2.10-14.el7cp (b05aecbcede52a89a654e9f2bec179c2050ddff6)
[root@magna024 cephmetrics-ansible]# rpm -qa | grep ansible
ceph-ansible-3.0.18-1.el7cp.noarch
cephmetrics-ansible-1.0-8.el7cp.x86_64
ansible-2.4.1.0-1.el7ae.noarch

How reproducible:
Always

Steps to Reproduce:
1. Followed the document https://doc-stage.usersys.redhat.com/documentation/en-us/red_hat_ceph_storage/3/html-single/administration_guide/#monitoring-ceph-clusters-with-the-red-hat-ceph-storage-dashboard, for installation
2. Created a vars.yml file as mentioned in the document.
3. Playbook fails with the following error.

TASK [ceph-grafana : Set grafana_data_source] *********************************************************************************************************************************************************************
fatal: [magna024.ceph.redhat.com]: FAILED! => {"failed": true, "msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'datasource'\n\nThe error appears to have been in '/usr/share/cephmetrics-ansible/roles/ceph-grafana/tasks/configure_grafana.yml': line 51, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Set grafana_data_source\n  ^ here\n\nexception type: <class 'ansible.errors.AnsibleUndefinedVariable'>\nexception: 'dict object' has no attribute 'datasource'"}


Actual results:
Fails with Error

Expected results:
The playbook should complete successfully.

Additional info:
[root@magna024 cephmetrics-ansible]# cat vars.yml 
grafana:
  admin_password: CGqf5HhUaZ

Comment 3 Boris Ranto 2018-04-25 10:22:16 UTC
Apparently, this was kinda by design, you were supposed to deploy with the default password and then change it in the web UI. Afterwards, you had to change the admin_password variable to be able to redeploy when updating dashboards, etc. This should still work.

I suppose this is not very well documented (it is in the code as a commentary).

I have a patch for this staged for 3.1 where you could directly deploy with a non-default password in this PR:

https://github.com/ceph/cephmetrics/pull/165

Given that there is no customer case attached, I'd probably rather keep this staged for 3.1 (the back-port would not apply cleanly due to recent changes and the PR is not merged, yet).

Any objections to pushing this to 3.1?

Comment 8 errata-xmlrpc 2018-09-26 18:18:23 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-2018:2819