[jira] [Updated] (HDDS-3519) Finalize network and storage protocol of Ozone

["Ethan Rose (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HDDS-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ethan Rose updated HDDS-3519:
-----------------------------
    Target Version/s: 1.3.0  (was: 1.2.0)

I am managing the 1.2.0 release and we currently have more than 600 issues targeted for 1.2.0. I am moving the target field to 1.3.0.

If you are actively working on this jira and believe this should be targeted for the 1.2.0 release, Please reach out to me via Apache email or Slack.

> Finalize network and storage protocol of Ozone
> ----------------------------------------------
>
>                 Key: HDDS-3519
>                 URL: https://issues.apache.org/jira/browse/HDDS-3519
>             Project: Apache Ozone
>          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: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org