[
https://issues.apache.org/jira/browse/HDDS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16869343#comment-16869343
]
Hudson commented on HDDS-1674:
------------------------------
FAILURE: Integrated in Jenkins build Hadoop-trunk-Commit #16801 (See
[https://builds.apache.org/job/Hadoop-trunk-Commit/16801/])
HDDS-1674. Make ScmBlockLocationProtocol message type based. (elek: rev
b95a58e231cb1ac87680a072d7fa84998fd95921)
* (edit)
hadoop-hdds/common/src/main/java/org/apache/hadoop/ozone/protocolPB/ScmBlockLocationProtocolServerSideTranslatorPB.java
* (edit)
hadoop-hdds/common/src/main/java/org/apache/hadoop/hdds/scm/protocolPB/ScmBlockLocationProtocolClientSideTranslatorPB.java
* (edit) hadoop-hdds/common/src/main/proto/ScmBlockLocationProtocol.proto
> 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
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
