Reorganize the plugins directory to group by plugin name rather than extension

[ahg-g]

What would you like to be added:

Reorganize the plugins directory to group by plugin name rather than extension

Why is this needed:
It makes it easier to navigate the code to look for a specific feature. I suggest the following structure:

plugins/kvcacheutilizationscorer
plugins/predictedlatencyscorer
...

[rockswe]

Hi Abdullah! @ahg-g Would you like me to work on this issue?

[ahg-g]

Thanks @rockswe; sure, but I would like to get alignment with the community on this proposal first

[rockswe]

Of course! Personally, I support the proposed directory layout as well.

[ahg-g]

@nirrozenbaum @kfswain @elevran thoughts?

[kfswain]

Would the file structure look like ./pkg/epp/plugins/.... This sounds like a good idea, just thinking through some of the details.

Would this potentially make ./pkg/epp/plugins/... very wide?

With the data layer changes, we will want to allow plugins to be more granular. For example: The Latency predictor plugin-set will want the prefix cache data production plugins, but not the prefix cache scorer. So then is it still okay to have all plugins related to prefix cache in one dir, and then others related to latency predictor in another? If a plugin uses a composite set of data (like the latency predictor does), what do we consider specific enough to include in the latency predictor dir, and what do we not?

Overall I think its a good idea to organize our plugins more centrally, I'm just uncertain if it should be by feature at the top level. I would like to wait until the Data Layer changes are complete before making a move though.

[nirrozenbaum]

Overall I think its a good idea to organize our plugins more centrally, I'm just uncertain if it should be by feature at the top level. I would like to wait until the Data Layer changes are complete before making a move though.

+1 here.

[elevran]

Organizing plugins by name would be easier to follow.
The concern is that we may have a proliferation of plugins all bundled under the same directory. Perhaps consider a intermediate level of "components" or "subsystem" (e.g., scheudling, data collection and organization, saturation, etc.)?

[ahg-g]

I agree with grouping the plugins into components. What data layer plugins do we expect to have? can you give examples?

[rahulgurnani]

I agree with grouping the plugins into components. What data layer plugins do we expect to have? can you give examples?

AFAIK, Examples of datalayer plugin:

1. prefix cache match plugin: Generates the prefix cache match percentage which is consumed by latency predictor.
   Suggested path: epp/datalayer/plugins/prefixcachematch
2. latency predictor plugin: Generates latency predictions for pods etc.

[elevran]

What data layer plugins do we expect to have? can you give examples?

there are data producing/consuming plugins, as noted by @rahulgurnani above.
there are also pkg/epp/datalayer plugins (e.g., model-server-protocol metrics collection data source and extractor). This is to support their management from a configuration file which handles plugin.Plugin generically.

We could either use plugins/<subsystem> or <subsystem>/plugins organization.
Not sure if everything that implements plugins.Plugin belongs under a shared plugins directory.

@ahg-g what scope (e.g., global or sub-system) do you have in mind?

[ahg-g]

I was also assuming that we will have some grouping, I prefer the plugins/<subsystem> structure since it it easier to navigate and gives us more flexibility in grouping

[ahg-g]

We can start with the scheduling ones if everyone is onboard with this.