HDDS-2999. Move server-related shared utilities from common to framework

[elek]

What changes were proposed in this pull request?

hdds-common project is shared between all the client and server projects. hdds-server-framework project is shared between all the server side services.

To reduce unnecessary dependencies (to Hadoop, for example) we can move all the server-side related classes (eg. rocksdb layer, certificate tools) to the framework from the common.

We don't need the rocksdb utilities and certificate tools on the client side.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-2999

How was this patch tested?

With maven build. This is only a compile level restructure of the code

[elek]

@anuengineer Next step forward to a Hadoop independent common. Please review if you have time (no logic has been changed just moving methods and classes between locations...)

[adoroszlai]

Thanks @elek for cleaning this up. LGTM, except removal of TestRatisHelper. Also, making tools depend on server-framework seems a bit awkward, but we can improve it later.

[elek]

Also, making tools depend on server-framework seems a bit awkward, but we can improve it later.

Agree. Earlier I proposed to rename all the proto files to use three categories:

• client protocols (eg. ozone-client, hdds-client proto): for the types which should be available from the client
• server protocols (for services between servers, like the cert client, can be blocked on the firewall from outside)
• admin protocols (for protocols used by admin cli tools)

We can organize the dependencies based on similar principals.

As of now we have:

• common (shared between servers and clients)
• framework (shared between servers)

We can create separated project for the shared classes between tools (cli) and servers ("admin" classes)

• common (shared between servers, clients, tools)
• framework (formerly common-serverside) (shared between servers)
• common-tools (shared between servers and tools)

I am not sure about the dependency hierarchy between common-tools and common but we can do it in the near future...