[PROPOSAL] Plugin naming conventions do not work well for community plugins

[lukas-vlcek]

What kind of business use case are you trying to solve? What are your requirements?

Clarify plugin naming conventions. Specifically for 3rd party / community plugins.

What is the problem? What is preventing you from meeting the requirements?
As of writing the plugin naming recommendations specifically recommend:

• not to include the plugin word in the repo name
• not to include the OpenSearch word in the repo name

I can understand that such naming conventions work well for plugins that are (or will be) included directly in the OpenSearch build or will become part of the OpenSearch core repo. But they do not work that great for all other cases when plugins are maintained by community members about the web.

For instance if there is community plugin for Prometheus exporter (for OpenSearch) then it makes sense to go directly against mentioned recommendations. You really want to make sure that the repo name includes both the plugin and OpenSearch words.

What are you proposing? What do you suggest we do to solve the problem or improve the existing situation?
Be more specific about proposed naming conventions. Clarify when it makes sense to follow these and when not.

What are your assumptions or prerequisites?
I assume that there will be proportionally more plugins that are not directly part of the core OpenSearch build process and maintenance organisation.

What are remaining open questions?
If there are any naming conventions that the community plugins shall follow then it is not clear where to find them.

[dblock]

I like the suggestion that the convention is for plugins that are included in the OpenSearch distribution that live within the OpenSearch org. You should PR that change.

Using https://github.com/lukas-vlcek/prometheus-exporter as an example is a good one. If it's a plugin for OpenSearch it should be called opensearch-prometheus-export-plugin. The name prometheus-exporteralone could be an exporter from anything as you correctly point out.

[dblock]

Thinking about this more, I think we made the wrong decision not to develop a convention for plugins regardless of whether they are in opensearch-project or not. When these projects fork I can no longer tell whether this is OpenSearch specific or not, ending up with job-scheduler-1 for X and job-scheduler-2 for Y in my forks. So job-scheduler should have been opensearch-job-scheduler-plugin.

Medium/long term I'd be open to revisiting the entire convention and maybe even renaming things. Would want to see a chart of repo names, plugin names in the plugin.descriptor, etc., and aligning those things.

[reta]

@dblock not necessarily disagree with you, but I think the general recommendations [1] make sense to me. All core plugins do follow this conventions (although they are not hosted in separate repositories). What probably makes sense is to separate the repository name (Github / Bitbucket / Gitlab) and plugin name:

• having opensearch- prefix for repository name would significantly simplify the discovery side (the prometheus-exporter in these regards is good example of confusing name, there are many repositories like that [2], opensearch-prometheus-exporter is arguably much better)
• having -plugin suffix is very likely redundant since this is a well known extension model for Opensearch: the majority would intuitively understand that (my opinion)
• having opensearch- or/and -plugin prefix/suffix in plugin name or plugin ZIP distribution name is certainly not needed, in these regards prometheus-exporter as plugin name looks acceptable and concise with most of the plugins out there: ingest-attachment, dsicovery-ec2, repository-s3, job-scheduler

[1] https://github.com/opensearch-project/opensearch-plugin-template-java/blob/fc0d230a807ab33990c354ffa8fc5a80bc2e86e2/README.md#create-your-plugin-repo-using-this-template
[2] https://github.com/discourse/prometheus_exporter

[dblock]

@lukas-vlcek Want to try to PR a change to the recommendations along ^ those ^ lines?

[lukas-vlcek]

@dblock I am on it (feel free to assign me). I think discussing particular details will be more productive over specific PR...

@reta I think there is important context information that the -plugin [suffix] represents.
The "plugin" word tells me that the system will be extended to directly output data in Prometheus format. Not having the "plugin" word tells me that we are dealing with a prometheus exporter in its strict form, ie. a side car running next to the monitored system (typically a tiny standalone proxy server). The side car pattern also means that if the system requires security then I will be responsible for setting up all the TLS/SSL and all the jazz for the proxy server myself, on the other hand when the target system is extended then usually its security settings can cover the extending point as well (which is the case of OpenSearch plugin).

In other words I can see that the following two terms represent two different things:

1. prometheus-exporter-for-opensearch
2. prometheus-exporter-plugin-for-opensearch

Also notice that I would prefer using the -for-opensearch suffix over opensearch- prefix mostly due to common trademark policies.

[reta]

@lukas-vlcek sure, was just sharing some thoughts, prometheus-exporter-for-opensearch looks good to me, as well as opensearch-prometheus-exporter (closer to my heart). I don't see trademark violation here since this is just the repository name, otherwise you may be going to rabbit hole of exporter-for-prometheus-for-opensearch since Prometheus. The documentation would have to refer to trademarks in a proper way.

[dblock]

Also notice that I would prefer using the -for-opensearch suffix over opensearch- prefix mostly due to common trademark policies.

Interesting. I personally find that unusual, what other projects do this?

Also, personally I love naming discussions :)

[saratvemulapalli]

Probably late to the conversation, but I like the new suggestions.
I believe when we started it was mostly focussed on plugins within the opensearch-project but I agree it should change.

Also there are few recommendations we put in for migrating and standards
It feels like the docs in this repo will eventually overlap, instead we should just have a single place for our readers/developers.

[AmiStrn]

Joining late as well:)
I agree with what was stated earlier - namely, (mind the pun) that naming should include opensearch for plugins outside the opensearch project repo.

@reta I think there is important context information that the -plugin [suffix] represents.

The -plugin suffix is indeed redundant imo. @lukas-vlcek - the example of having it in the middle is not as a suffix, I agree in that context it can be part of the name just not a suffix.

Interesting. I personally find that unusual, what other projects do this?

Not for plugins, but as a convention there is... ODFE 😆

I agree with @saratvemulapalli that this should be fixed in this repo's documentation - the naming should reference the other repo's recommendations and not explicitly state them here.

[lukas-vlcek]

Please have a look at my PR #27

In general I would like to see this to be specified in STANDARDS.md document but as of now it does not contain any specific naming convention details that can be elaborated (or have I missed anything?).
Thus I added it into README.md document for now (and I also added steps/check specific to 3rd party plugins only that may not fit well into STANDARDS.md document).

Feedback welcome.