Thoughts on having OpenSearch identifier in all things plugins

While we are upgrading all the ODFE plugins to work with OpenSearch, we realized all the APIs, settings, indices etc had a prefix of opendistro.
How would you like to see all things plugins in opensearch-project ? Would you like to have opensearch prefixed for every API, settings, indices etc? Or the other way round?


POST _opendistro/_anomaly_detection/detectors to POST _opensearch/_anomaly_detection/detectors or POST _anomaly_detection/detectors

Here is the github issue if you’d like to chime in there.

Maybe start with a deprecation warning while supporting both endpoints at first and change it a few versions in? The concern is obviously backwards compatibility

1 Like

Thats a great point. Definitely. We will always be backwards compatible, support the old API for a while and if needed could be deprecated in later versions.

Mostly the question is about what should be the new/existing APIs/indices etc be named to?

I am guessing the simplest solution would be a general redirect of [cluster]/_opendistro/* to [cluster] /_opensearch/*, and that should probably take care of that as well

Also - any changes to this would be post 1.0 GA, right?

Since we have decided ODFE is end of life. I believe these changes should be part of 1.0 GA, i.e get rid of opendistro everywhere. Do you have other suggestions/thoughts?

That would make a breaking change - I’m pretty sure the project is committed to no breaking changes in 1.0.

Yeah definitely. We will not make breaking changes. All changes we make will be backwards compatible and we are putting our thoughts into it.
Here are the items which are named opendistro today: Support rolling upgrades for OpenSearch plugins, and restart upgrades for OpenSearch Dashboards Plugins 1.0 · Issue #12 · opensearch-project/opensearch-plugins · GitHub

Re-posting the comment from github issue, just another thought.

We could meet somewhere in between which works for everybody.
What do you guys think of something like _opendistro/_anomaly_detection/*_plugins/_anomaly_detection/* .
No more having OpenSearch in it, also we can clearly distinguish that these paths are from plugins.

Same with indices, settings, permissions etc. Please vote/voice your opinions.


+1, I like the idea of _plugins.

+1 _plugins . project/product name doesn’t seem necessary in api.

+1 _plugins :slight_smile:
This fits what I would normally expect an API to look like.

how do you ensure that two plugins from different “vendors” (i’m using this as a generic term here, they don’t have to be companies, can also be a random person on github) don’t use the same name? you probably don’t have a copyright/trademark e.g. on _anomaly_detection (and even if you do, others might not have one on their plugin name). using a vendor prefix usually alleviates these issues.
it’s the same with java: you also don’t name your package foo, you name it because foo isn’t unique.

using _plugins as another prefix in front of that in turn helps prevent that any vendor (or, if you leave that out, plugin) name collides with any future plans for new endpoints in the core product. otherwise you’d either need a complete list of all plugins which exist (which you can’t have since some will probably never be published) or accept potentially breaking a plugin (making any new API endpoint automatically a new major release according to semver).

=> i’d go for /_plugins/somevendor/someplugin. so in your example /_plugins/opensearch/_anomaly_detection.

which brings me to the next question: why the _ prefix for the plugin name? if it’s prefixed with /_plugins you don’t need it in the plugin name again. and also for /_plugins i’m not sure whether you need the _ prefix (though that might be an elasticsearch/opensearch convention? there are a bunch of APIs with this prefix)

you could treat opensearch core plugins in a special way and e.g. say that instead of writing opensearch as the vendor you can shorten it to just _ => /_plugins/_/anomaly_detection

lastly: why the snake_case in the plugin name in the URL? most REST API guidelines (see e.g. Zalando RESTful API and Event Guidelines) mandate hyphenated words in the path segments.

+1 for this.

@ralph - Isn’t this API only relevant to the OpenSearch project’s plugins? Otherwise, yes you are correct that a “vendor” may be required in the path.

the discussion was so far focusing on renaming opendistro plugins to opensearch plugins, that’s true. i took it and kind-of spun it out a bit to a wider discussion. i have a tendency to do that, sorry about that :smiley:

1 Like

:slight_smile: Thanks @ralph for putting in thoughts beyond opendistro plugins. I intended to cover all the plugins in the community, and taking opendistro as an example to start with.

I did go through the Rest API guidelines, but OpenSearch pretty much follows that convention of using _ instead of -. So it makes sense for the plugins to continue to do that until OpenSearch changes its convention. We could open up an issue on the OpenSearch repo to discuss and vote on it.

Looks like everybody likes for _plugins/_anomaly_detection, and it’s sold.
I’ll update the github issue.

Anybody if they have strong opinions against this, please voice out.

1 Like