Elek, Marton created HDDS-1068:
----------------------------------
Summary: Improve the error propagation for ozone sh
Key: HDDS-1068
URL: https://issues.apache.org/jira/browse/HDDS-1068
Project: Hadoop Distributed Data Store
Issue Type: Improvement
Components: Ozone Manager
Reporter: Elek, Marton
Assignee: Elek, Marton
Attachments: HDDS-1068.001.patch
As of now the server side (om, scm) errors are not propagated to the client.
For example if ozone is started with one single datanode:
{code}
docker-compose exec ozoneManager ozone sh key put -r THREE /vol1/bucket1/test2
NOTICE.txt
Create key failed, error:KEY_ALLOCATION_ERROR
{code}
There is no information here about the missing datanodes, or missing pipelines.
There are multiple problems which should be fixed:
1. type safety
In ScmBlockLocationProtocolClientSideTranslatorPB the server (om) side
exceptions are transformed to IOException where the original status is added to
the message:
For example:
{code}
throw new IOException("Volume quota change failed, error:" + resp.getStatus());
{code}
In s3 gateway it's very hard to handle the different errors in a proper way.
The current code:
{code}
if (!ex.getMessage().contains("KEY_NOT_FOUND")) {
result.addError(
new Error(keyToDelete.getKey(), "InternalError",
ex.getMessage()));
{code}
2. message
The exception message is not propagated in the om response just the status code
3. status code and error message are handled in a different way
To propagate error code and status code to the client we need to handle them in
the same way. But the Status field is part of the specific response objects
(CreateVolumeRequest) and not the OMRequest. I propose to put both StatusCode
and error message to the OMRequest.
4. The status codes in OzoneManagerProtocol.proto/Status enum is not in sync
with OmException.ResultCodes.
It would be easy to use the same strings for both enums. With a unit test we
can ensure that they have the same names in the same order.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
