opensearch-project / opensearch-api-specification

API specification for OpenSearch
Apache License 2.0
34 stars 62 forks source link

[FEATURE] Add missing API specs #168

Open dblock opened 11 months ago

dblock commented 11 months ago

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?

  1. Specs up-to-date to the latest distribution of OpenSearch.
  2. A way to know which specs aren't up-to-date (a tool)?

How can you help?

  1. Open any recent pull request.
  2. Scroll to checks, pick the "Analyze PR Changes" job and look at its logs. It will bring you to, for example, https://github.com/opensearch-project/opensearch-api-specification/actions/runs/10871915073/job/30166319109?pr=578.
  3. Find "Calculate Coverage". All the APIs missing in the spec are there. Screenshot 2024-09-15 at 10 50 05 AM
  4. Add one!

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.

nhtruong commented 10 months ago

@dblock are they all plugins/extensions or do some of them going to be a core feature of OS?

dblock commented 10 months ago

@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.

nhtruong commented 7 months ago

@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 commented 7 months ago

@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.

I think _opendistro is there for backwards compat, we should not include it.

dblock commented 7 months ago

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?

nhtruong commented 7 months ago

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:

dblock commented 7 months ago

@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.

nhtruong commented 7 months ago

https://github.com/opensearch-project/opensearch-api-specification/pull/257 will generate the _opendistro endpoint if the _plugins equivalents exist.

dbwiddis commented 4 months ago

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.)

dblock commented 4 months ago

(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.

Screenshot 2024-07-19 at 5 36 48 PM