[BUG] Failing to start OpenSearch from Search Processor #162
Comments
|
Very thorough explanation. Do other plugins take a dependency on another plugin to shorten build times? |
Looks like it. Going through the other dashboards plugins, all of them start OpenSearch from a single plugin. Typically, they use plugins that are the respective backends. For example,
In order for Side note, many of these plugins, don't follow the plugin repository naming conventions. Dashboards plugins should prefix with |
macohen
changed the title
|
As it turns out, OpenSearch was failing when adding sample data since there were analyzers missing. The issue stemmed from the integration tests, which were using |
github-project-automation
bot
moved this from 👀 In review
to ✅ Done
in Search Project Board
Overview
Following opensearch-project/dashboards-search-relevance#177 (about two months ago), all
Remote integ tests workflowruns have failed with varying errors. This change was to implement an automated version bump to match OpenSearch and OpenSearch Dashboards versions. In particular,.github/workflows/remote-integ-tests-workflow.ymlwas updated to fetch versions from the otheropensearch-projectrepos. This PR also included a change from usinganomaly-detectiontosearch-processoras a dependency for OpenSearch. Our Cypress integration tests require a running OpenSearch Dashboards instance, which also itself requires a running OpenSearch instance. To alleviate the long OpenSearch setup through checking out the main repo, we can run OpenSearch from a plugin. We switched fromanomaly-detectiontosearch-processor, since many of the maintainers ofdashboards-search-relevanceare also maintainers onsearch-processor. In theory, ifanomaly-detectionbuilds fail, this repo would be blocked until their maintainers fix the issue.Cause of Failure
Taking a look at this run, OpenSearch and OpenSearch Dashboards seemingly build successfully. However, upon starting the Cypress tests, errors occur immediately with a connection refused error. Typically speaking, this error is occurs when OpenSearch Dashboards cannot connect to OpenSearch (most likely because OpenSearch isn't running). However, we do have a check to see if the OpenSearch instance started successfully before proceeding to the other steps.
After some testing on my local, I found that
search-processorcan start an instance of OpenSearch successfully with./gradlew run -Dopensearch.version=<version>, as well as connect succesfully to OpenSearch Dashboards uponyarn start, but it fails once there are any interactions with OpenSearch Dashboards. In my testing to replicate the above action on version2.8.1, I first set up OpenSearch withsearch-processorusing the command./gradlew run -Dopensearch.version=2.8.1, verifying that it started withcurl localhost:9200. Then, I started a2.8.1version instance of OpenSearch Dashboards. After using commandcurl localhost:5601to verify OpenSearch Dashboards setup, thesearch-processorinstance of OpenSearch fails. Below is a portion of thesearch-processorlogs .Full logs can be viewed here
Resolution/Mediation
For purposes of release, I rolled back our dependency from
search-processortoanomaly-detectionfor the time being. This change to the workflow is in opensearch-project/dashboards-search-relevance#230. In order to satisfy the correct OpenSearch version dependencies, I specified the workflow to use a-SNAPSHOTpostfix to be passed in when starting OpenSearch, since unreleased versions of OpenSearch require a-SNAPSHOTtag (3.0.0,2.8.1, etc.).This issue is to track the progress on the OpenSearch dependency. Currently, our options are to:
anomaly-detectionplugin and hope they maintain the plugin in a successful statesearch-processor.The text was updated successfully, but these errors were encountered: