Description of problem: 'osd pool create' recommends using expected_num_objects on bluestore based clusters. This parameter is only useful on filestore clusters. Version-Release number of selected component (if applicable): ceph-common.x86_64 2:12.2.8-36.el7cp Steps to Reproduce: 1. # osd pool create <pgnum> For better initial performance on pools expected to store a large number of objects, consider supplying the expected_num_objects parameter when creating the pool. Actual results: cmd issues recommendation if pgnum exceeds threshold Expected results: cmd detects backing store type and only issues recommendation if on filestore based cluster and pgnum exceeds threshold Additional info:
This occurs because the internal default value for osd_objectstore (even in master upstream) is still "filestore". That doesn't affect ceph-disk or ceph-volume, but it fools the check used by this warning.
This does not sound like a blocker to 3.2. Can we re-target this to 4.0?
Moving to MODIFIED, as it was merged in upstream. I think CLOSED-NEXTRELEASE would be a good status for this one.
This is fixed in all nautilus-based builds. Backporting to earlier releases required too many test changes, so moving this to 4.0.
Updating the QA Contact to a Hemant. Hemant will be rerouting them to the appropriate QE Associate. Regards, Giri
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-2020:0312