Open dblock opened 11 months ago
@dblock are they all plugins/extensions or do some of them going to be a core feature of OS?
@dblock are they all plugins/extensions or do some of them going to be a core feature of OS?
Lots in core. I updated the list above.
@dblock are we doing both _plugins
and _opendistro
? We can totally DRY this. I'll need to update the validator to account for this. I'm also going to do this for knn
namespace as an example.
@dblock are we doing both
_plugins
and_opendistro
? We can totally DRY this. I'll need to update the validator to account for this. I'm also going to do this forknn
namespace as an example.
I think _opendistro
is there for backwards compat, we should not include it.
I should probably take that back, if we want to claim coverage we need some way to know about these and skip them. Maybe the right way would be to mark them deprecated? What's the correct way to do that @nhtruong?
I'm thinking of having a file named _opendistro.yaml
that looks like this:
_reports/on_demand/{reportDefinitionId}: POST
_rollup/jobs: GET,PUT
It will be loaded up with all _plugins/...
endpoints that have the _opendistro/...
equivalents. The merger tool will take this file into account and generate the opendistro endpoints that are identical to the plugins counterparts but with deprecated
and x-ignored
set to true
. This has a few benefits:
spec
folder tidy and free of hundreds of deprecated endpoints@nhtruong This is a good plan. I would make sure this is expressed with data in the files in _opendistro, e.g. via some kind of ref: another API
.
https://github.com/opensearch-project/opensearch-api-specification/pull/257 will generate the _opendistro endpoint if the _plugins equivalents exist.
Can you add flow framework to the list in the original comment?
We're feeling a bit left out. ;)
(Yeah, we hadn't released yet when the list was drafted, which points out that you need a way to identify any new plugins and add them.)
(Yeah, we hadn't released yet when the list was drafted, which points out that you need a way to identify any new plugins and add them.)
We actually do. This little box in every PR compares all the available APIs in OpenSearch with the spec and tells you how many unspecified paths we have.
Is your feature request related to a problem?
The spec repo should be 100% of specs that ship with OpenSearch and kept up-to-date.
What solution would you like?
How can you help?
What is the current state of API specs in this repo?
Do you have any additional context?
This is what's missing per https://github.com/dblock/opensearch-api-specification/actions/runs/7495103121/job/20404497220#step:10:1, generated via https://github.com/opensearch-project/opensearch-api-specification/pull/179.