Ceph » rbd

This originated in the context of "rbd feature disable" operation getting proxied, ETIMEDOUT error returned by DisableFeaturesRequest and "rbd feature disable" command getting stuck in a busy loop, see https://tracker.ceph.com/issues/58740. While DisableFeaturesRequest is getting changed to avoid generating ETIMEDOUT error in that particular case in https://github.com/ceph/ceph/pull/50593, a general issue we have is that an operation handler is allowed to return an arbitrary error code. If it happens to return ETIMEDOUT (not because of a notification-related issue but just on it's own) while being executed on behalf of some other client (i.e. a "remote" request), the client gets into a busy loop.

If the operation handler is executed locally and happens to return ETIMEDOUT, the error is propagated to the API immediately. If the same operation handler is executed remotely and returns ETIMEDOUT exactly the same way, the requestor gets into a busy loop and the API appears to hang. This applies to all operations that can be proxied.

"Remote" requests should be made to behave exactly the same as a "local" requests as far as error propagation goes; operation proxying must be completely transparent to the user.