Uploaded image for project: 'Hadoop Distributed Data Store'
  1. Hadoop Distributed Data Store
  2. HDDS-1068

Improve the error propagation for ozone sh

    XMLWordPrintableJSON

    Details

    • Target Version/s:

      Description

      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:

      docker-compose exec ozoneManager ozone sh key  put -r THREE /vol1/bucket1/test2 NOTICE.txt             
      Create key failed, error:KEY_ALLOCATION_ERROR
      

      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:

       throw new IOException("Volume quota change failed, error:" + resp.getStatus());
      

      In s3 gateway it's very hard to handle the different errors in a proper way. The current code:

      if (!ex.getMessage().contains("KEY_NOT_FOUND")) {
                  result.addError(
                      new Error(keyToDelete.getKey(), "InternalError",
                          ex.getMessage()));
      

      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.

        Attachments

        1. HDDS-1068.001.patch
          162 kB
          Marton Elek
        2. HDDS-1068.002.patch
          241 kB
          Marton Elek
        3. HDDS-1068.003.patch
          247 kB
          Marton Elek

          Issue Links

            Activity

              People

              • Assignee:
                elek Marton Elek
                Reporter:
                elek Marton Elek
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 20m
                  20m