[
https://issues.apache.org/jira/browse/HDDS-1674?focusedWorklogId=262207&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-262207
]
ASF GitHub Bot logged work on HDDS-1674:
----------------------------------------
Author: ASF GitHub Bot
Created on: 18/Jun/19 10:56
Start Date: 18/Jun/19 10:56
Worklog Time Spent: 10m
Work Description: sodonnel commented on pull request #984: HDDS-1674 Make
ScmBlockLocationProtocol message type based
URL: https://github.com/apache/hadoop/pull/984
This PR is a first attempt at refactoring the ScmBlockLocationProtocol using
a single message type as is used in the OzoneManagerProtocol. In this change,
the new message wraps the existing messages and the translator classes simply
wrap or unwrap it.
Only TraceID has been moved to the wrapper message - Moving error handling
and error codes to the wrapper will be done in a separate change.
Before this can be merged we still need to determine if the clientId should
be present in the ScmBlockLocationProtocol. It is in OzoneManagerProtocol and
has been replicated here for now, but it can be removed if needed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 262207)
Time Spent: 10m
Remaining Estimate: 0h
> 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: 10m
> 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]
