Known Issues

`ceph-deploy` tool not compatible with previous releases

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)

`ceph-deploy purge` command does not clean up OSD disk volumes or labels

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)

Some RBD features not supported in UEK R5

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)

Ceph Object Gateway does not support HTTP and HTTPS concurrently

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)

NFS exports using nfs-ganesha are read-only if SELinux enabled

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)

TLS SecurityWarning: Certificate has no subjectAltName

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)

ceph-deploy tool not compatible with previous releases

ceph-deploy purge command does not clean up OSD disk volumes or labels