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! 🚀

[dbwiddis]

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.

Hi @zelinh, we have already onboarded all our APIs to the api specification here which you correctly call out as a prerequisite.

However, we also have written yaml tests there, see https://github.com/opensearch-project/opensearch-api-specification/blob/main/tests/default/flow_framework/workflow.yaml which seem a lot more thorough, actually testing the functionality.

This effort seems duplicative (and not nearly as robust). Does this smoke test provide added value over those api spec tests?

[zelinh]

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.

Hi @zelinh, we have already onboarded all our APIs to the api specification here which you correctly call out as a prerequisite.

However, we also have written yaml tests there, see https://github.com/opensearch-project/opensearch-api-specification/blob/main/tests/default/flow_framework/workflow.yaml which seem a lot more thorough, actually testing the functionality.

This effort seems duplicative (and not nearly as robust). Does this smoke test provide added value over those api spec tests?

Hey @dbwiddis,

Yes, the smoke test framework is specifically designed to validate OpenSearch distribution bundles, including TAR, RPM, and DEB packages, as part of the release process. These tests enhance release quality by ensuring each distribution type is systematically verified.

To my knowledge, the tests in the api-spec repository primarily run against staging Docker images. Onboarding to this framework will provide more efficient and comprehensive sanity testing across all release artifacts, improving reliability and reducing manual effort in the release cycle.