[jira] [Assigned] (HDDS-1674) Make ScmBlockLocationProtocol message type based

["Elek, Marton (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HDDS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Elek, Marton reassigned HDDS-1674:
----------------------------------

    Assignee: Stephen O'Donnell  (was: Shweta)

> Make ScmBlockLocationProtocol message type based
> ------------------------------------------------
>
>                 Key: HDDS-1674
>                 URL: https://issues.apache.org/jira/browse/HDDS-1674
>             Project: Hadoop Distributed Data Store
>          Issue Type: Improvement
>            Reporter: Elek, Marton
>            Assignee: Stephen O'Donnell
>            Priority: Major
>
> Most of the Ozone protocols are "message type based" and not "method based".
> For example in OzoneManagerProtocol.proto there is only one method:
> {code}
> service OzoneManagerService {
>     // A client-to-OM RPC to send client requests to OM Ratis server
>     rpc submitRequest(OMRequest)
>           returns(OMResponse);
> }
> {code}
> And the exact method is determined by the type of the message:
> {code}
> message OMResponse {
>   required Type cmdType = 1; // Type of the command
>   // A string that identifies this command, we generate  Trace ID in Ozone
>   // frontend and this allows us to trace that command all over ozone.
>   optional string traceID = 2;
>   optional bool success = 3 [default=true];
>   optional string message = 4;
>   required Status status = 5;
>   optional string leaderOMNodeId = 6;
>   optional CreateVolumeResponse              createVolumeResponse          = 11;
>   optional SetVolumePropertyResponse         setVolumePropertyResponse     = 12;
>   optional CheckVolumeAccessResponse         checkVolumeAccessResponse     = 13;
> ....
> }
> enum Type {
>   CreateVolume = 11;
>   SetVolumeProperty = 12;
>   CheckVolumeAccess = 13;
>   InfoVolume = 14;
>   DeleteVolume = 15;
>   ListVolume = 16;
> ....
> {code}
> This is not the most natural way to use protobuf services but it has the additional benefit that we can propagate traceId / exception in a common way.
> Earlier there was an agreement to modify all the protocols to use this "message type based" approach to make it possible to provide proper error handling.
> In this issue  the ScmBlockLocationProtocol.proto should be modified to use only one message:
> {code}
> service ScmBlockLocationProtocolService {
>   rpc send (SCMBlockLocationRequest) returns (SCMBlockLocationResponse);
> }
> {code}
> It also requires to create the common request and response objects (with the common fields like type, traceId, success, message, status as they are used in the OzoneManagerProtocol.proto).
> To make it work, the ScmBlockLocationProtocolClientSideTranslatorPB and the ScmBlockLocationProtocolServerSideTranslatorPB should be improved to wrap/unwrap the original message to/from the generic message. 
> I propose to only the protocol change here (if possible) we can keep the message/status fields empty and fix the error propagation in HDDS-1258



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org