crimson/osd: allow ops with non-empty hobject key

Crimson was rejecting OSD ops when hobject_t::key (locator) was non-empty,
returning -ENOTSUP (95). This broke RGW PutObject because RGW uses locators
for object names like "bucket/obj" to ensure objects land in the same PG.

The original code comment claimed locators were only used for multipart
upload clone_range, which is no longer supported. However, RGW still uses
locators for the fundamental object naming scheme, so this check was
incorrectly blocking basic RGW operations.

This fixes s3tests PutObject failing with HTTP 500 / internal error -95
Signed-off-by: Kautilya Tripathi <kautilya.tripathi@ibm.com>

diff --git a/src/crimson/osd/osd_operations/client_request.cc b/src/crimson/osd/osd_operations/client_request.cc
index 1073b55d7a20bebe31a0dc84280072b1c004462d..f21ec89e2d833847b4001508d5a37b3b4b5be6da 100644 (file)
--- a/src/crimson/osd/osd_operations/client_request.cc
+++ b/src/crimson/osd/osd_operations/client_request.cc
@@ -150,14 +150,6 @@ ClientRequest::interruptible_future<> ClientRequest::with_pg_process_interruptib
   // enter_stage.
   ihref.enter_stage_sync(client_pp(pg).wait_pg_ready, *this);
 
-  if (!m->get_hobj().get_key().empty()) {
-    // There are no users of locator. It was used to ensure that multipart-upload
-    // parts would end up in the same PG so that they could be clone_range'd into
-    // the same object via librados, but that's not how multipart upload works
-    // anymore and we no longer support clone_range via librados.
-    co_await reply_op_error(pgref, -ENOTSUP);
-    co_return;
-  }
   if (pg.can_discard_op(*m)) {
     co_await interruptor::make_interruptible(
       shard_services->send_incremental_map(