[
https://issues.apache.org/jira/browse/HDDS-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arpit Agarwal updated HDDS-3519:
--------------------------------
Component/s: build
> Finalize network and storage protocol of Ozone
> ----------------------------------------------
>
> Key: HDDS-3519
> URL: https://issues.apache.org/jira/browse/HDDS-3519
> Project: Hadoop Distributed Data Store
> Issue Type: Improvement
> Components: build
> Reporter: Marton Elek
> Priority: Critical
> Labels: TriagePending
>
> One of the next releases of Ozone can be named as GA which means that
> backward compatibility should be more important.
> Before GA I propose to cleanup the current RPC interface and stabilize the
> storage interface.
> Goals:
> * Clearly define the client / storage interfaces and monitor the changes
> * Separate Client RPC from intra-service / admin interfaces (for security
> reasons)
> * Remove unusued / out-of date messages
> I propose the following steps
> 1. We should separate client / admin / server calls on the services.
> -> Majority of existing calls are "client" calls, used by the client
> -> Admin calls are supposed to be used by admin CLI (local only in a secure
> environment
> -> Server calls are intra-server calls (like db HB)
> 2. We should use unified naming convention
> 3. protocol files can be moved to separated maven project to make it easier
> to reuse from language binding and make it easier to monitor API change
> 4. We should use RDBStore interface everywhere instead of the old
> Metadatastore interface
> 5. We can move all the table definition interfaces to separated project and
> monitor the API changes
> This is my previous proposal for naming convetion, which was discussed and
> accepted during one of the community meetings:
> {quote}My simplified name convention suggest to separate only the server
> (like om2scm) the client (like client2om) and admin (like pipeline list, safe
> mode administration, etc.) protocol services.
> 1. admin services should be available only from the cluster (use
> ....AdminProtocol as name)
> 2. client can be available from inside and outside (use ....ClientProtocol as
> name)
> 3. server protocol can be restricted to be used only between the services.
> (use ......ServerProtocol as name)
> Based on this convention:
> --> OMClientProtocol
> Should contain all the client calls (OzoneManagerProtocol)
> --> OMAdminProtocol
> It's a new service can contain the new omha commands
> --> SCMAdminProtocol
> Can contain all the admin commands from StorageContainerLocation protocol
> (QueryNode, InsafeMode, ....)
> --> SCMClientProtocol
> It seems that we don't need it any more as client doesn't require any
> connection to the SCM (please confirm)
> --> SCMServerProtocol (server2server calls)
> * Remaining part of the StorageContainerLocation protocol (allocate
> container, get container)
> * Content of the SCMSecurityProtocol.proto
> * Content of SCMBlockLocationProtocol
> -> SCMHeartbeatProtocol
> Well, it's so specific that we can create a custom postfix instead of Server.
> This is the HB (StorageContainerDatanodeProtocol)
> -> DatanodeClientProtocol
>
> Chunks, upload from the DatanodeContainerProtocol
> --> DatanodeServerProtocol
> There is one service here which publishes the container.tar.gz for the other
> services. As of now it's combined with the DatanodeClientProtocol.
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
