opensearch-api-specification
opensearch-api-specification copied to clipboard
Added Query Set API Specs
Description
Added some specifications for the query sets in the search relevance workbench.
Issues Resolved
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license. For more information on following Developer Certificate of Origin and signing off your commits, please check here.
@wrigleydan can you give some eyes to the specific SRW apis defined here?
We are very interested in understanding if @ajleong623 has appropriately structured a new API addition. The underlying effort is the new Search Relevance Workbench, coming in 3.1!
Great start to have specs to our APIs! Thanks @ajleong623
We might want to add a little to distinguish PUT and POST from each other: Currently PUT is to create a query set by uploading queries manually, and POST creates a query set by sampling queries from user behavior data.
In general, I think x-version-added needs to be 3.1 everywhere, since we aim for a 3.1 release for these APIs (see https://github.com/opensearch-project/opensearch-api-specification/blob/main/DEVELOPER_GUIDE.md#openapi-extensions).
Spec tests would be awesome so that we not only have a description but actually use the specs to validate our developments and see when we need to update things. (see https://github.com/opensearch-project/opensearch-api-specification/blob/main/DEVELOPER_GUIDE.md#writing-spec-tests). I don't know if that's a hard requirement but I definitely think that tests would help us in the development process.
I don't know if that's a hard requirement but I definitely think that tests would help us in the development process.
Tests are a hard requirement. Thanks!
@ajleong623 do we need to cut a version of the search-relevance plugin that you can refer to in the spec tests (and somehow load into the opensearch fired up via docker?)
@epugh, unfortunately, I am not sure. All I did was ./gradlew run on the search-relevance repository when I had to connect to a cluster for the tests.
@ajleong623 You'll need the plugin installed and tests to pass in CI. See https://github.com/opensearch-project/opensearch-api-specification/blob/main/TESTING_GUIDE.md.
@dblock I donβt think the plugin has been distributed at the moment, so I am not sure if I can install it. I will just write the rest of the specs for the search relevance workbench APIs for now then figure out how to install it.
You can install a -SNAPSHOT build of it.
The functional tests and the snapshot have been added for all the listed queries.
@ajleong623 mark this PR ready when it's ready and we can take a look
I think it is ready, but how do I run the CI tests?
I think it is ready, but how do I run the CI tests?
They should have kicked off. Not sure why they aren't π€
Either way this is a new plugin setup that would need to be added to https://github.com/opensearch-project/opensearch-api-specification/blob/main/.github/workflows/test-spec.yml, so rebase your PR and add that?
I added the workflows. What was preventing the tests from running was that the changelog was not being cleanly merged, but I resolved the conflict. I think someone also has to approve the workflows.
Changes Analysis
Commit SHA: 4b0a9a0e901e90adb352577312bff95a3ab79830 Comparing To SHA: 3ce15ec9e2cc1e73a192ce937646009e56a76ec4
API Changes
Summary
βββ¬Paths
β βββ[β] path (9515:3)
β βββ[β] path (9468:3)
β βββ[β] path (9546:3)
β βββ[β] path (9437:3)
β βββ[β] path (9374:3)
β βββ[β] path (9405:3)
β βββ[β] path (9577:3)
β βββ[β] path (9343:3)
βββ¬Components
βββ[β] requestBodies (30384:7)
βββ[β] requestBodies (30398:7)
βββ[β] responses (34371:7)
βββ[β] responses (34346:7)
βββ[β] responses (34304:7)
βββ[β] requestBodies (30453:7)
βββ[β] requestBodies (30469:7)
βββ[β] requestBodies (30414:7)
βββ[β] responses (34338:7)
βββ[β] responses (34322:7)
βββ[β] responses (34354:7)
βββ[β] responses (34316:7)
βββ[β] responses (34298:7)
βββ[β] responses (34365:7)
βββ[β] responses (34330:7)
βββ[β] responses (34310:7)
βββ[β] responses (34380:7)
βββ[β] responses (34391:7)
βββ[β] parameters (26193:7)
βββ[β] parameters (26221:7)
βββ[β] parameters (26186:7)
βββ[β] parameters (26200:7)
βββ[β] parameters (26214:7)
βββ[β] parameters (26207:7)
βββ[β] parameters (26228:7)
βββ[β] parameters (26235:7)
βββ[β] schemas (64961:7)
βββ[β] schemas (64944:7)
βββ[β] schemas (64933:7)
βββ[β] schemas (64976:7)
βββ[β] schemas (64908:7)
| Document Element | Total Changes | Breaking Changes |
|---|---|---|
| paths | 8 | 0 |
| components | 31 | 0 |
- Total Changes: 39
- Additions: 39
Report
The full API changes report is available at: https://github.com/opensearch-project/opensearch-api-specification/actions/runs/15540384280/artifacts/3298982160
API Coverage
| Before | After | Ξ | |
|---|---|---|---|
| Covered (%) | 663 (64.94 %) | 663 (64.94 %) | 0 (0 %) |
| Uncovered (%) | 358 (35.06 %) | 358 (35.06 %) | 0 (0 %) |
| Unknown | 70 | 87 | 17 |
@ajleong623 I clicked the approve button, iterate to π’ , will keep doing that
I am still working on having all the tests and the linter ones pass.
I think that the tests are passing because I ran the linter tests on my end.
Edit: I actually still need approval from maintainers for the workflows.
Looks like we are getting some warnings still, but getting closer!
WARNING Multiple paths detected, please group similar tests together and move paths not being tested to prologues or epilogues.
WARNING Invalid path detected, please move /tests/plugins/search_relevance/experiments.yaml to plugins/search_relevance/query_sets.yaml.
WARNING Invalid path detected, please move /tests/plugins/search_relevance/experiments.yaml to plugins/search_relevance/search_configurations.yaml.
Looks like we are getting some warnings still, but getting closer!
WARNING Multiple paths detected, please group similar tests together and move paths not being tested to prologues or epilogues. WARNING Invalid path detected, please move /tests/plugins/search_relevance/experiments.yaml to plugins/search_relevance/query_sets.yaml. WARNING Invalid path detected, please move /tests/plugins/search_relevance/experiments.yaml to plugins/search_relevance/search_configurations.yaml.
Looking better!
@epugh are there still warnings on your end? I do not see it on my end.
@Xtansia if itβs possible, could you please review the updated changes?
Spec Test Coverage Analysis
| Total | Tested |
|---|---|
| 637 | 635 (99.69 %) |
Overall looks OK. I have an important question below.
Less important in the code there are a few things like "I am not sure why ..." change those to clear TODO: figure out ...
@ajleong623 if you want some help reformulating those comments into more action oriented.. Also, maybe ping @sstults on if we can actually get someting more specific ;-). Getting closer!
@dblock I changed the comments to now begin with TODO and the specific action that can be taken. Also, @epugh answered the more important question about the build.
@epugh @ajleong623 I am still not clear on whether CI will start suddenly failing with a future build of OpenSearch 3.1. The Dockerfile uses opensearchstaging/opensearch:3.1.0 which is a moving target, while the -SNAPSHOT build of the plugin being downloaded is a fixed, manually uploaded version. So I think we have to use a fixed SHA or download a latest matching build for both the plugin and OpenSearch core, or wait till 3.1.0 gets released and the plugin gets released to add it here?
@dblock @epugh in test-spec.yml, I specified the sha to use for testing found here: https://hub.docker.com/layers/opensearchstaging/opensearch/3.1.0/images/sha256-72ce9569524d12a2af5912a84c72ea73639aee0e9af04e56584cbc84be8899b3. Is that the right approach with using a fixed sha?
@dblock @epugh in test-spec.yml, I specified the sha to use for testing found here: https://hub.docker.com/layers/opensearchstaging/opensearch/3.1.0/images/sha256-72ce9569524d12a2af5912a84c72ea73639aee0e9af04e56584cbc84be8899b3. Is that the right approach with using a fixed sha?
Maybe? i hope these SHA stay for a while and don't go away..
One reason I am pushing on this is that I'm hoping in 3.1 to use this api spec in the documentation for the Plugin. However, it may be that we have a kind of chicken/egg thing. We need OpenSearch 3.1, the new API spec, and our plugin all to land ;-) It may be that merging this and tweaking the docs to reference this has to happen after 3.1 and the plugin are released?
Is that the right approach with using a fixed sha?
Yes, this looks better now.
@ajleong623 there is one more API added to search-relevance recently, stats API https://github.com/opensearch-project/search-relevance/issues/47. Do we need to update spec and include new API?