[
https://issues.apache.org/jira/browse/HDFS-11857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chen Liang updated HDFS-11857:
------------------------------
Description:
Currently, StorageContainerLocationProtocolServerSideTranslatorPB has two
protocol impls:
{{StorageContainerLocationProtocol impl}}
{{ScmBlockLocationProtocol blockImpl}}.
the class provides container-related services by invoking {{impl}}, and
block-related services by invoking {{blockImpl}}. Namely, on server side, the
implementation makes a distinguish between "container protocol" and "block
protocol".
An issue is that, currently, everywhere except for the server side is viewing
"container protocol" and "block protocol" as different. More specifically,
StorageContainerLocationProtocol.proto still includes both container operation
and block operation in itself alone. As a result of this difference, it is
difficult to implement certain APIs (e.g. putKey) properly from client side.
This JIRA merges "block protocol" back to "container protocol" in
StorageContainerLocationProtocolServerSideTranslatorPB, to unblock the
implementation of other APIs for client side.
Please note that, in the long run, separating these two protocols does seem to
be the right way. This JIRA is only a temporary solution to unblock developing
other APIs. Will need to revisit these protocols in the future.
Thanks [~xyao] for the offline discussion.
was:
Currently, StorageContainerLocationProtocolServerSideTranslatorPB has two
protocol impls:
{{StorageContainerLocationProtocol impl}}
{{ScmBlockLocationProtocol blockImpl}}.
the class provides container-related services by invoking {{impl}}, and
block-related services by invoking {{blockImpl}}. Namely, on server side, the
implementation makes a distinguish between "container protocol" and "block
protocol".
An issue is that, currently, everywhere except for the server side is viewing
"container protocol" and "block protocol" as different. More specifically,
StorageContainerLocationProtocol.proto still includes both container operation
and block operation in itself alone. As a result of this difference, it is
difficult to implement certain APIs (e.g. putKey) properly from client side.
This JIRA merges "block protocol" back to "container protocol" in
StorageContainerLocationProtocolServerSideTranslatorPB, to unblock the
implementation of other APIs for client side.
Please note that, in the long run, separating these two protocols does seem to
be the right way. This JIRA is only a temporary solution to unblock developing
other APIs. Will need to revisit these protocols in the future.
> Ozone : need to refactor
> StorageContainerLocationProtocolServerSideTranslatorPB
> -------------------------------------------------------------------------------
>
> Key: HDFS-11857
> URL: https://issues.apache.org/jira/browse/HDFS-11857
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Chen Liang
> Assignee: Chen Liang
> Attachments: HDFS-11857-HDFS-7240.001.patch
>
>
> Currently, StorageContainerLocationProtocolServerSideTranslatorPB has two
> protocol impls:
> {{StorageContainerLocationProtocol impl}}
> {{ScmBlockLocationProtocol blockImpl}}.
> the class provides container-related services by invoking {{impl}}, and
> block-related services by invoking {{blockImpl}}. Namely, on server side, the
> implementation makes a distinguish between "container protocol" and "block
> protocol".
> An issue is that, currently, everywhere except for the server side is viewing
> "container protocol" and "block protocol" as different. More specifically,
> StorageContainerLocationProtocol.proto still includes both container
> operation and block operation in itself alone. As a result of this
> difference, it is difficult to implement certain APIs (e.g. putKey) properly
> from client side.
> This JIRA merges "block protocol" back to "container protocol" in
> StorageContainerLocationProtocolServerSideTranslatorPB, to unblock the
> implementation of other APIs for client side.
> Please note that, in the long run, separating these two protocols does seem
> to be the right way. This JIRA is only a temporary solution to unblock
> developing other APIs. Will need to revisit these protocols in the future.
> Thanks [~xyao] for the offline discussion.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
