Uploaded image for project: 'Apache Ozone'
  1. Apache Ozone
  2. HDDS-3519

Finalize network and storage protocol of Ozone

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Critical
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: build
    • Labels:
    • Target Version/s:

      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.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              elek Marton Elek
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated: