[HDDS-3519] Finalize network and storage protocol of Ozone

• Type: Improvement
• Status: Open
• Priority: Critical
• Resolution: Unresolved
• Component/s: build
• Labels: TriagePending non_1.4.0_blocker
• Target Version/s: 1.5.0
• Assignee: Unassigned
• Reporter: Marton Elek
• Created: 04/May/20 12:51
• Updated: 24/Jan/24 09:17

Description

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:

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.

Issue Links

• is a parent of: HDDS-4216 Separate storage / RPC proto files