[ 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: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org