Onboard OpenSearch plugins to Smoke tests framework

[zelinh]

Sub-issue from opensearch-project/opensearch-build#5317

Background

With the smoke test framework (#5223) now established, we have successfully onboarded multiple OpenSearch plugins—including Index Management, Security, SQL, and K-NN—to the framework (PR #5255).

To maximize the effectiveness of smoke testing, we aim to onboard all OpenSearch plugins into the framework. This effort will enhance overall testing coverage, ensuring greater reliability and functionality validation for OpenSearch and its plugins.

Overview of Smoke Tests

Smoke tests verify the basic functionality of an OpenSearch distribution bundle with all plugins installed. Each plugin has its own test specification YAML file, stored in the OpenSearch Build repository and organized by major version.

These YAML files list API test cases, which the smoke test workflow executes. The results are then validated against the OpenSearch API Specification to ensure API correctness and expected behavior.

How to Onboard a Plugin

To onboard your plugin to the smoke test framework, follow the Onboarding Guide.

Steps to Onboard:

1. Add a YAML test file

   • Create a new test file for your plugin in the relevant major version directory under smoke_tests_spec.
   • Example: security.yml.

2. Define API tests in the YAML file

   • Specify:
     • API path
     • HTTP method
     • Request body (if applicable)
     • Custom Content-Type header if different from application/json.
   • See an example test definition here.

3. Ensure the APIs are onboarded to the OpenSearch API Specification repository

   • Before adding APIs to smoke tests, they must be present in the OpenSearch API Specification repository.
   • Refer to the Developer Guide for onboarding steps.

4. Reference the test file in the test manifest

   • Ensure the newly added YAML file is referenced in the test manifest for your plugin’s component.

Collaboration with Plugin Owners:

We are reaching out to all OpenSearch plugin owners to facilitate onboarding. We will provide:
✅ Documentation and guidelines for onboarding.
✅ Support in setting up test cases.
✅ Assistance in troubleshooting issues.

Expected Outcome:

• Stronger OpenSearch releases with better validation of plugins.
• Standardized, reusable testing framework for ongoing plugin validation.
• Faster detection of integration issues before release.

📢 Plugin owners: We encourage you to onboard your plugin to the smoke test framework! If you have any questions or need assistance, feel free to comment on this issue or reach out to EE team.

Let’s work together to strengthen OpenSearch’s testing and release process! 🚀

[pyek-bot]

@zelinh is there a timeline we are targeting for onboarding?

[ylwu-amzn]

Sounds a good way to automate our manual sanity test

[zelinh]

@zelinh is there a timeline we are targeting for onboarding?

We are targeting this to be onboarded by 3.0.0 release.

[rithin-pullela-aws]

Hi @mingshl can you please assign this to me.

[rithin-pullela-aws]

@mingshl @dhrubo-os, can we close this issue.
Resolved by this PR: opensearch-project/opensearch-build#5369

[mingshl]

Thanks @rithin-pullela-aws for taking this up! closed this issue and marked as done