osd/OSDMap: do not require ERASURE_CODE feature of clients

Just because an EC pool exists in the cluster does not mean tha tthe client
has to support the feature:

1) The way client IO is initiated is no different for EC pools than for
   replicated pools.
2) People may add an EC pool to an existing cluster with old clients and
   locking those old clients out is very rude when they are not using the
   new pool.
3) The only direct client user of EC pools right now is rgw, and the new
   versions already need to support various other features like CRUSH_V2
   in order to work.  These features are present in new kernels.

Fixes: #8556
Backport: firefly
Signed-off-by: Sage Weil <sage@inktank.com>
(cherry picked from commit 3fe1699f9620280d0070cfe6f01cfeb2332e7470)

diff --git a/src/osd/OSDMap.cc b/src/osd/OSDMap.cc
index 8329bdd615d07624796ebb5697483e95eb5ba85d..1b41b1dc467249c66207c97ee1fdc6c649192621 100644 (file)
--- a/src/osd/OSDMap.cc
+++ b/src/osd/OSDMap.cc
@@ -970,7 +970,8 @@ uint64_t OSDMap::get_features(int entity_type, uint64_t *pmask) const
     if (p->second.flags & pg_pool_t::FLAG_HASHPSPOOL) {
       features |= CEPH_FEATURE_OSDHASHPSPOOL;
     }
-    if (p->second.is_erasure()) {
+    if (p->second.is_erasure() &&
+       entity_type != CEPH_ENTITY_TYPE_CLIENT) { // not for clients
       features |= CEPH_FEATURE_OSD_ERASURE_CODES;
     }
     if (!p->second.tiers.empty() ||