MINOR Moved tiered storage API classes from clients module to a new storage-api module.

[satishd]

MINOR Moved tiered storage API classes from clients module to a new storage-api module.
Created storage and storage-api modules. All the remote storage API classes are moved to storage-api module. All the remote storage implementation classes will be added to storage module.

Committer Checklist (excluded from commit message)

• Verify design and implementation
• Verify test coverage and CI build status
• Verify documentation (including upgrade notes)

[satishd]

@junrao Raised this PR as you suggested earlier about moving client classes to a separate module. I created storage-api submodule and moved all the remote storage API classes into that module.

[junrao]

@satishd : Thanks for the PR. LGTM

[ijuma]

Thanks. Will we use separate packages for the api vs implementation? We should avoid split packages for the reasons mentioned here: https://www.logicbig.com/tutorials/core-java-tutorial/modules/split-packages.html

[satishd]

Thanks @ijuma for bringing this up.

Discussed earlier having api as the suffix for the API related classes. New package name in storage:api module becomes org.apache.kafka.server.log.remote.storage.api.
cc @junrao

[ijuma]

One option is to use log.remote.storage as the public api package and add internals for the non public. That's similar to what we do for the clients api. We need to verify that this works fine with the module system (I haven't checked in detail if subpackages in separate modules would cause issues, but I'd hope not).

[ijuma]

Also cc @kowshik

[kowshik]

I just looked at the clients code under kafka/clients/. As an example to @ijuma's suggestion, I see the interface: org.apache.kafka.common.KafkaFuture and its implementation in: org.apache.kafka.common.internals.KafkaFutureImpl. This type of separation looks good too.

@ijuma Does the existing approach in this PR have any disadvantages, or the suggestion to use .internals has more to do with being consistent with how we do it in clients already? I read the article linked above, but I wasn't sure if it'd apply to us here, but I could be wrong.

cc @satishd @junrao

[ijuma]

This PR has the same package in two separate jars. That is what's called "split packages" in the article above.

[satishd]

One option is to use log.remote.storage as the public api package and add internals for the non public. That's similar to what we do for the clients api. We need to verify that this works fine with the module system (I haven't checked in detail if subpackages in separate modules would cause issues, but I'd hope not).

@ijuma I am fine with this approach. It looks like we plan to have this convention for all the modules across the repo.

[junrao]

Yet another option is to have a new server-api module. We can move the following server side apis that are currently in the client module to the new module.
include "/org/apache/kafka/server/authorizer/*"
include "/org/apache/kafka/server/policy/"
include "**/org/apache/kafka/server/quota/"

If so, we can move the storage api there too.