Bug 1418577 - following upgrade documentation for ceph possibly breaks functionnality of OpenStack
Summary: following upgrade documentation for ceph possibly breaks functionnality of Op...
Alias: None
Product: Red Hat Ceph Storage
Classification: Red Hat
Component: Documentation
Version: 2.1
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: 2.2
Assignee: Aron Gunn
QA Contact: ceph-qe-bugs
Depends On:
TreeView+ depends on / blocked
Reported: 2017-02-02 08:31 UTC by Petr Barta
Modified: 2020-03-11 15:43 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-03-21 23:49:53 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Petr Barta 2017-02-02 08:31:38 UTC
Description of problem:

In Installation Guide for Red Hat Enterprise Linux - Red Hat Ceph Storage (https://access.redhat.com/documentation/en/red-hat-ceph-storage/2/paged/installation-guide-for-red-hat-enterprise-linux/chapter-5-upgrading-ceph-storage-cluster), there is instruction for changing ownership of several directories, like for example:

Chapter 5.1.1 Upgrading a Ceph Monitor Node

5. As root, update the owner and group permissions:

# chown -R <owner>:<group> <path_to_directory>


# chown -R ceph:ceph /var/lib/ceph/mon
# chown -R ceph:ceph /var/log/ceph
# chown -R ceph:ceph /var/run/ceph
# chown -R ceph:ceph /etc/ceph

Similar examples are in different places throughout the document.

The last command can potentially break function of OpenStack commands, when monitoring node is running on OSP controller nodes. 
We have seen this for glance/cinder not being able to upload image to storage, because ownership for following keyring files was incorrectly set to ceph:ceph, instead of correct glance:glance, and cinder:cinder, respectively.

$ ls -al /etc/ceph
-rw-------.  1 ceph ceph      64 <date> ceph.client.cinder.keyring
-rw-------.  1 ceph ceph      64 <date> ceph.client.glance.keyring

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

Ceph storage monitoring running on OSP controller nodes.

How reproducible:


Steps to Reproduce:

Actual results:

Expected results:

Additional info:

  The best way would be to specify exat files which need to have changed ownership.
  Second best way is to make a note that in such a situation files which are used by OSP need to have appropriate ownership/access rights set up.

Note You need to log in before you can comment on or make changes to this bug.