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?
Example:
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
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
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?
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.
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 org.opensearch.foo 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.
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
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.
