The ceph-deploy tool provided in this release is not compatible with previous Ceph Storage for Oracle Linux releases. Using the ceph-deploy provided in this release to manage deployments from previous releases may result in errors and unexpected behavior. Make sure you upgrade your environment using the steps set out in Upgrading Ceph Storage Cluster Nodes to avoid using the latest ceph-deploy tool with older deployments.

(Bug 28049396)

By design, the ceph-deploy purge command does not remove existing OSD volume groups or labels. This is to avoid unintentional data destruction. After purging an OSD, the volume remains in use, and any attempt to reuse it results in an error similar to the following:

# ceph-deploy osd create ceph-1 --data /dev/sdb 
...
# ceph-deploy purge ceph-1 
...
# ceph-deploy osd create ceph-1 --data /dev/sdb 
...
[DEBUG ]  stderr: Can't open /dev/sdb exclusively.  Mounted filesystem? 
[DEBUG ] --> Was unable to complete a new OSD, will rollback changes 
[DEBUG ] --> OSD will be fully purged from the cluster, because 
the ID was generated 
[DEBUG ] Running command: ceph osd purge osd.0 --yes-i-really-mean-it 
[DEBUG ]  stderr: purged osd.0 
[ERROR ] RuntimeError: command returned non-zero exit status: 1 
[ceph_deploy.osd][ERROR ] Failed to execute command: /usr/sbin/ceph-volume 
--cluster ceph lvm create --bluestore --data /dev/sdb 
[ceph_deploy][ERROR ] GenericError: Failed to create 1 OSDs 

Workaround: Remove the volume group and volume label used for the OSD on the disk. The disk can then be used to create a new volume the next time you use the ceph-deploy osd create command. For example, to remove a volume label, use the lvdisplay command to list the volume labels, and delete the label:

# lvdisplay
...
# lvremove --force /dev/ceph-dc39f7cc-e423-48d3-a466-9701e7bf972a/osd-block-f7db38d2-...

Use the vgdisplay command to list the volume groups, and delete the group:

# vgdisplay
...
# vgremove --force ceph-dc39f7cc-e423-48d3-a466-9701e7bf972a

(Bug 27748402)

An error may be displayed when mapping an image to a block device using the RBD kernel module, for example:

# rbd map vol01 --pool datastore 
rbd: sysfs write failed 
RBD image feature set mismatch. You can disable features unsupported by the 
kernel with "rbd feature disable datastore/vol01 object-map fast-diff 
deep-flatten". 
In some cases useful info is found in syslog - try "dmesg | tail". 
rbd: map failed: (6) No such device or address 

UEK R5 does not support all RBD features. Unsupported features must be disabled.

Workaround: Disable the object-map, fast-diff, and deep-flatten RBD features before mapping an image to a block device, for example:

# rbd create --size 4096 --pool datastore vol01
# rbd feature disable datastore/vol01 object-map fast-diff deep-flatten
# rbd map vol01 --pool datastore

(Bug 28028199)

Although upstream documentation suggests that it is possible to configure the Ceph Object Gateway to support both HTTP and HTTPS at the same time, by specifying two ports concatenated with the + symbol and by appending the s character to the port number where SSL/TLS should be used, this functionality does not work properly and only the first port specified is used.

Only configure for one protocol at a time, until this issue is resolved.

(Bug 24422558)

If SELinux is enabled, NFS exports using nfs-ganesha are read-only. This affects Ceph FS and Ceph Object Gateway over NFS using nfs-ganesha.

Workaround: Disable SELinux. Edit the /etc/sysconfig/selinux file and change SELINUX=enforcing to SELINUX=disabled. Reboot the host.

(Bug 28036218)

When you configure a Ceph Object Gateway instance and enable Transport Layer Security (TLS) you must create or use a certificate. If the certificate does not have the v3 extension enabled and the subjectAltName set within the certificate, a warning message is displayed when a client such as the Swift client attempts to access the gateway:

/usr/lib/python2.7/site-packages/urllib3/connection.py:251: SecurityWarning:
Certificate has no `subjectAltName`, falling back to check for a `commonName`
for now. This feature is being removed by major browsers and deprecated by
RFC 2818. (See https://github.com/shazow/urllib3/issues/497 for details.)

If a subjectAltName extension of type dNSName is present, this is used as the identity. Otherwise, the Common Name field in the Subject field of the certificate is used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.

Workaround: Use a certificate in PEM format with the v3 extension enabled (X.509v3). See Enabling Transport Layer Security and Configuring Transport Layer Security for information on creating and using self-signed certificates.

(Bug 24424028)