Elek, Marton created HDDS-1674:
----------------------------------
Summary: 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: Shweta
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-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
