RESOURCE_EXHAUSTED ambiguous

[pohly]

Reusing existing gRPC status codes leads to ambiguities for the CO. RESOURCE_EXHAUSTED can be returned by the gRPC transport layer, for example when message sizes are exceeded.

Therefore a CO which gets that error cannot be sure whether it was the driver which returned that status. For example, a CreateVolume call is specified as returning RESOURCE_EXHAUSTED when space is exhausted in a certain topology. The right reaction by the CO then is to try elsewhere. But if the error came from the transport layer, then the CO has to try again with larger message sizes.

In the worst case, CreateVolumeRequest went through and CreateVolumeResponse didn't. Treating this like "space exhausted" leaks a volume.

Pointed out by @jsafrane in https://github.com/kubernetes-csi/external-provisioner/pull/405#discussion_r386976638.

[jdef]

is this the only error code that is ambiguous? probably not. if "overlapping" error codes is a concern, then there's probably a bigger design decision to make re: error codes. we punted on this before, but maybe it's time to resurface?

On Tue, Mar 24, 2020 at 11:58 AM Patrick Ohly [email protected] wrote:

Reusing existing gRPC status codes leads to ambiguities for the CO. RESOURCE_EXHAUSTED can be returned by the gRPC transport layer, for example when message sizes are exceeded.

Therefore a CO which gets that error cannot be sure whether it was the driver which returned that status. For example, a CreateVolume call is specified as returning RESOURCE_EXHAUSTED when space is exhausted in a certain topology. The right reaction by the CO then is to try elsewhere. But if the error came from the transport layer, then the CO has to try again with larger message sizes.

In the worst case, CreateVolumeRequest went through and CreateVolumeResponse didn't. Treating this like "space exhausted" leaks a volume.

Pointed out by @jsafrane https://github.com/jsafrane in kubernetes-csi/external-provisioner#405 (comment) https://github.com/kubernetes-csi/external-provisioner/pull/405#discussion_r386976638 .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/container-storage-interface/spec/issues/419, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAR5KLEB7RMVODEVXKGUB6TRJDKBJANCNFSM4LSYVDXQ .

-- James DeFelice 585.241.9488 (voice) 650.649.6071 (fax)

[pohly]

We noticed this for RESOURCE_EXHAUSTED and a solution just for that would be already a step forward.

But I agree, this looks like a more fundamental design issue. On the other hand, I haven't checked whether other gRPC codes have the same problem.