Code Duplication in Cloud Plugins

[kartg]

Is your feature request related to a problem? Please describe. There seems to be duplication of logic in the code for Cloud Plugins. This is an opportunity for us to streamline the codebase and refactor these classes. This issue stems from these comments in #2096.

Describe the solution you'd like Move common functionality to superclasses and have the Cloud Plugins inherit/extend these in platform-specific subclasses.

Describe alternatives you've considered N/A

Additional context N/A

[willyborankin]

Small investigation I made.

Common code I found: List of common classes and functions for proxy settings in all cloud plugins:

• ProxySettings - could be a generic type, since all clients have they own ProxyType
• *Settings classes - the function validateAndCreateProxySettings has the same code for all plugins Common functions:
• all *Settings::getConfigValue and *Settings::getValue classes use the same logic to get settings

Common settings:

• client
• compress
• readonly
• chunk_size
• base_path
• all proxy stettings

Common class:

• SocketAccess - it is the same for all plugins

I think it is possible to build high level abstraction for the plugin and re-use it in plugins. I tried to do it here https://github.com/aiven/aiven-repositories-for-opensearch, the code is far from ideal, maybe you will find it usefull.

[willyborankin]

@CEHENKLE and @kartg if you are still interested in refactoring cloud repositories. I can help with it. Wdyt?

[kartg]

@willyborankin we're definitely still interesting in refactoring these plugins. Would you be willing to attempt a first pass with one of the plugins, and we can iteratively refactor the rest?

[willyborankin]

Sure will prepare PR during this week

[sourav25998]

Hello @kartg . This issue seems to be a nice start to my open source contribution journey. Can you please assign this to me?

[dblock]

@sourav25998 i don’t think we can use assignments on GH due to permissions, but go for it! Make a PR

[kartg]

@dblock 👆 😉