You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-dev@hadoop.apache.org by "Elek, Marton (JIRA)" <ji...@apache.org> on 2019/02/07 13:12:00 UTC

[jira] [Created] (HDDS-1068) Improve the error propagation for ozone sh

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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-help@hadoop.apache.org