opensearch-project / dashboards-query-workbench Goto Github PK

Received Error: Error building OpenSearch-Dashboards, retry with: ./build.sh manifests/1.3.8/opensearch-dashboards-1.3.8.yml --component OpenSearch-Dashboards.
The distribution build for OpenSearch-Dashboards has failed.
Please see build log at https://build.ci.opensearch.org/job/distribution-build-opensearch-dashboards/5407/consoleFull

@opensearch-ci-bot commented on Thu Jan 12 2023

Received Error: Error building OpenSearch-Dashboards, retry with: ./build.sh manifests/3.0.0/opensearch-dashboards-3.0.0.yml --component OpenSearch-Dashboards.
The distribution build for OpenSearch-Dashboards has failed.
Please see build log at https://build.ci.opensearch.org/job/distribution-build-opensearch-dashboards/5360/consoleFull

@kavilla commented on Tue Jan 17 2023

Looks like the relative path change for build script. Workbench team should look in relative path.

What is the bug?
A call is being made to:
http://localhost:5601/api/spark_sql_console/job/undefined
Which is leading to:

{
    "data": {
        "ok": false,
        "resp": "Bad Request",
        "body": "{\n  \"status\": 400,\n  \"error\": {\n    \"type\": \"IllegalArgumentException\",\n    \"reason\": \"Invalid Request\",\n    \"details\": \"Last unit does not have enough valid bits\"\n  }\n}"
    }
}

Is there something wrong with setup?

How can one reproduce the bug?
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

What is the expected behavior?
A clear and concise description of what you expected to happen.

What is your host/environment?

• OS: [e.g. iOS]
• Version [e.g. 22]
• Plugins

Do you have any screenshots?
If applicable, add screenshots to help explain your problem.

Do you have any additional context?
Add any other context about the problem.

Introduction

As part of our continued efforts to improve OpenSearch Dashboards, we are planning to upgrade the underlying Node.js version from v14 to v18. This change will enhance performance, add new features, and bolster security. However, such major version changes might also affect the compatibility of existing plugins. Here is more introduction: opensearch-project/OpenSearch-Dashboards#3601.

Therefore, we kindly request assistance in testing this plugin the compatibility of with this new version of Node.js. We've prepared a branch with the Node.js v18 upgrade, which you can find here:
https://github.com/AMoo-Miki/OpenSearch-Dashboards/tree/node-18-webpack-4

Steps to Proceed

• If you think your plugin won't be affected by OpenSearch Dashboards Node.js upgrade. Pls ignore the rest steps and close the issue directly.
• Pull the provided branch that includes the Node.js v18 upgrade and OpenSearch 3.0.0.
• Hook up your plugin with the updated OpenSearch Dashboards.
• Run your existing test suites and perform manual testing as necessary.
• If no issues are encountered, feel free to close this issue.
• If there are any problems, report them in this issue thread and also link them in the overall OpenSearch Dashboards Node.js upgrade issue thread opensearch-project/OpenSearch-Dashboards#4058
  The purpose of linking any questions or issues back to the main issue is to maintain visibility and transparency among all plugin owners. A problem encountered by one plugin might also affect others. This shared knowledge base will foster collaborative problem-solving and prevent duplication of effort.

We appreciate your support and cooperation in ensuring a smooth transition to Node.js v18 for the entire OpenSearch Dashboards community.

What is the bug?
Query workbench has problem with the highlight function results shown as screenshot below.

How can one reproduce the bug?
Steps to reproduce the behavior:

1. Go to 'Query Workbench'
2. Enter query SELECT host, highlight(message) FROM opensearch_dashboards_sample_data_logs WHERE host = "www.opensearch.org" AND MATCH(message, "GET 503 Linux", operator="AND");
3. Click on 'Run' button
4. Click on any link in highlight(message) column
5. See error

What is the expected behavior?
Query workbench should be able to show the full result and even render the HTML <em> tag:

POST _plugins/_sql
{
  "query": """
   SELECT host, highlight(message) FROM opensearch_dashboards_sample_data_logs WHERE host = "www.opensearch.org" AND MATCH(message, "GET 503 Linux", operator="AND");
  """
}
{
  "schema": [
    {
      "name": "host",
      "type": "text"
    },
    {
      "name": "highlight(message)",
      "type": "nested"
    }
  ],
  "datarows": [
    [
      "www.opensearch.org",
      [
        """106.225.58.146 - - [2018-07-22T03:49:40.669Z] "<em>GET</em> /apm_1 HTTP/1.1" <em>503</em> 0 "-" "Mozilla/5.0 (X11; <em>Linux</em>"""
      ]
    ],
...

What is your host/environment?

• OS: Mac
• Version: 2.2
• Plugins: OpenSearch SQL

Do you have any screenshots?

Do you have any additional context?
N/A

Hi team,

we did experience a strange behavior of Kibana when upgrading it to the latest version of ODFE 1.13.2.
Describe the bug

Zone_rules_exception “Unknown time-zone ID: Browser”

This doesn't happen when using Browser as a default time zone but rather when changing it to e.g. "UTC" and upgrading the ODFE version. It may be related to the cache and it gets resolved by doing "force refresh" e.g. on Chome via Ctrl + R. I just wanted to report it in case the ODFE team wants to debug a bit further on the issue.

Here is the error user gets on Kibana:

zone_rules_exception
Unknown time-zone ID: Browser
Error: Bad Request
    at Fetch._callee3$ (https://<host>/36136/bundles/core/core.entry.js:6:59535)
    at tryCatch (https://<host>/36136/bundles/plugin/opendistroQueryWorkbenchKibana/opendistroQueryWorkbenchKibana.plugin.js:1:32004)
    at Generator.invoke [as _invoke] (https://<host>/36136/bundles/plugin/opendistroQueryWorkbenchKibana/opendistroQueryWorkbenchKibana.plugin.js:1:35968)
    at Generator.forEach.prototype.<computed> [as next] (https://<host>/36136/bundles/plugin/opendistroQueryWorkbenchKibana/opendistroQueryWorkbenchKibana.plugin.js:1:33129)
    at fetch_asyncGeneratorStep (https://<host>/36136/bundles/core/core.entry.js:6:52652)
    at _next (https://<host>/36136/bundles/core/core.entry.js:6:52968)

and it seems to be coming mostly from opendistroQueryWorkbenchKibana.

To Reproduce

• Install the previous version of ODFE using Debian Package.
• Set time-zone to UTC on Stack Managment --> Advanced Settings -- Kibana
• Upgrade it to the latest via Rolling Upgrade.
• Upgrade Kibana as well :

  sudo apt install -y opendistroforelasticsearch-kibana
  sudo /bin/systemctl start kibana.service
  

After these steps are done, open Kibana URL, and you will see an Error message (as above) complaining that Zone_rules_exception “Unknown time-zone ID: Browser”

Expected behavior
Should be able to pick up the time-zone setup in Kibana.

Plugins
Default pluginns shiped with ODFE.

Host/Environment (please complete the following information):

• OS: ubuntu
• Version 1804-bionic

Is your feature request related to a problem? Please describe.
When erroneous queries on query workbench are ran, the error output is currently generic <queryInput>: Bad Request, this query is not runnable. instead of containing detailed error message output (e.g no such index <indexName>)

Describe the solution you'd like
Change the error response body to display full detailed error output.

@opensearch-ci-bot commented on Tue Jan 10 2023

Received Error: Error building OpenSearch-Dashboards, retry with: ./build.sh manifests/2.5.0/opensearch-dashboards-2.5.0.yml --component OpenSearch-Dashboards.
The distribution build for OpenSearch-Dashboards has failed.
Please see build log at https://build.ci.opensearch.org/job/distribution-build-opensearch-dashboards/5309/consoleFull

@kavilla commented on Tue Jan 10 2023

+ cd plugins/queryWorkbenchDashboards
+ yarn plugin-helpers build --opensearch-dashboards-version=2.5.0
yarn run v1.22.19
error Command "plugin-helpers" not found. Did you mean "plugin_helpers"?

What is the bug?
A clear and concise description of the bug.
https://future.playground.opensearch.org/app/opensearch-query-workbench
-> dark mode should work consistently with each coloring on each query view.

How can one reproduce the bug?
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

What is the expected behavior?
A clear and concise description of what you expected to happen.

What is your host/environment?

• OS: [e.g. iOS]
• Version [e.g. 22]
• Plugins

Do you have any screenshots?
If applicable, add screenshots to help explain your problem.

Do you have any additional context?
Add any other context about the problem.

This is a component issue for 3.0.0.
Coming from opensearch-project/opensearch-build#3747. Please follow the following checklist.
Please refer to the DATES in that post.

Preparation

• Assign this issue to a release owner.
• Finalize scope and feature set and update the Public Roadmap.
• All the tasks in this issue have been reviewed by the release owner.
• Create, update, triage and label all features and issues targeted for this release with v3.0.0.

CI/CD

• All code changes for 3.0.0 are complete.
• Ensure working and passing CI.
• Check that this repo is included in the distribution manifest.

Pre-Release

• Update to the 3.0.0 release branch in the distribution manifest.
• Increment the version on the parent branch to the next development iteration.
• Gather, review and publish release notes following the rules and back port it to the release branch.git-release-notes may be used to generate release notes from your commit history.
• Confirm that all changes for 3.0.0 have been merged.
• Add this repo to the manifest for the next developer iteration.

Release Testing

• Find/fix bugs using latest tarball and docker image provided in parent release issue and update the release notes if necessary.
• Code Complete: Test within the distribution, ensuring integration, backwards compatibility, and performance tests pass.
• Sanity Testing: Sanity testing and fixing of critical issues found.
• File issues for all intermittent test failures.

Release

• Complete documentation.
• Verify all issued labeled for this release are closed or labelled for the next release.
• Verify the release date mentioned in release notes is correct and matches actual release date.

Post Release

• Prepare for an eventual security fix development iteration by incrementing the version on the release branch to the next eventual patch version.
• Add this repo to the manifest of the next eventual security patch version.
• Suggest improvements to this template.
• Conduct a retrospective, and publish its results.

What is the bug?
This is related to opensearch-project/sql#644
Once that gets implemented, the current rules for distinguishing describe response from show response doesn't work anymore.

How can one reproduce the bug?

What is the expected behavior?
COLUMN_NAME should also be rendered

Do you have any additional context?
This happens because previously, we can't filter the fields of the responses of show and describe for SQL, while describe in PPL allows that.
Workaround: seankao-az/sql@ppl-describe...seankao-az:workbench-describe-render

Summary

With 2.9.0 release, there are lot of enhancements going in for segment replication[1][2] feature (went GA in 2.7.0), we need to ensure different plugins are compatible with current state of this feature. Previously, we ran tests on plugin repos to verify this compatibility but want plugin owners to be aware of these changes so that required updates (if any) can be made

What changed

1. Refresh policy behavior

1. RefreshPolicy.IMMEDIATE will only refresh primary shards but not replica shards immediately. Instead post refresh, primary will start a round of segment replication to update the replica shard copies leading to eventual consistency.
2. RefreshPolicy.WAIT_UNTIL ensures the indexing operation is searchable in your cluster i.e. RAW (Read after write guarantee). With segment replication, this guarantee is not promised due to delay in replica shared updates from asynchronous background refreshes.

2. Refresh lag on replicas

With segment replication, there is inherent delay in documents to be searchable on replica shard copies. This is due to the fact that replica shard copies over data (segment) files from primary. Thus, compared to document replication, there will be on average increase in amount of time the replica shards are consistent with primaries.

3. System/hidden indices support

With opensearch-project/OpenSearch#8200, system and hidden indices are now supported with SEGMENT replication strategy. We need to ensure there are no bottlenecks which prevents system/hidden indices with segment replication.

Next steps

With segment replication strong reads are not guaranteed. Thus, if the plugin needs strong reads guarantees specially as alternative to change in behavior of refresh policy and lag on replicas (point 1 and 2 above), we need to update search requests to target primary shard only. With opensearch-project/OpenSearch#7375, core now supports primary shards only based search. Please follow documentation for examples and details

Open questions

In case of any questions or issues, please post it in core issue

Reference

[1] Design
[2] Documentation

This is a component issue for 2.6.0.
Coming from opensearch-build__3081__. Please follow the following checklist.
Please refer to the DATES in that post.

Preparation

• Assign this issue to a release owner.
• Finalize scope and feature set and update the Public Roadmap.
• All the tasks in this issue have been reviewed by the release owner.
• Create, update, triage and label all features and issues targeted for this release with v2.6.0.

CI/CD

• All code changes for __2.6.0__ are complete.
• Ensure working and passing CI.
• Check that this repo is included in the distribution manifest.

Pre-Release

• Update to the __2.6__ release branch in the distribution manifest.
• Increment the version on the parent branch to the next development iteration.
• Gather, review and publish release notes following the rules and back port it to the release branch.git-release-notes may be used to generate release notes from your commit history.
• Confirm that all changes for __2.6.0__ have been merged.
• Add this repo to the manifest for the next developer iteration.

Release Testing

• Find/fix bugs using latest tarball and docker image provided in parent release issue and update the release notes if necessary.
• Code Complete: Test within the distribution, ensuring integration, backwards compatibility, and performance tests pass.
• Sanity Testing: Sanity testing and fixing of critical issues found.
• File issues for all intermittent test failures.

Release

• Complete documentation.
• Verify all issued labeled for this release are closed or labelled for the next release.
• Verify the release date mentioned in release notes is correct and matches actual release date.

Post Release

• Prepare for an eventual security fix development iteration by incrementing the version on the release branch to the next eventual patch version.
• Add this repo to the manifest of the next eventual security patch version.
• Suggest improvements to this template.
• Conduct a retrospective, and publish its results.

Coming from opensearch-project/opensearch-build#4161

What is happening?

We are planning 2.11.1 release in upcoming few weeks. Following the semver guildelines and branching strategy, this release will be based on 2.11 as a reference branch

Why?

1. We need this release because of a critical breaking bug in the security plug-in. This bug impacts everyone using logstash and the only work around is to turn off compression (which is expensive)

2. As a refresher, our normal process is to commit changes to main, then backport to 2.x. Since the 1.0 release, we only backport bug fixes and security changes to the current 2.x branch (in this case 2.11) so that if we need to we can quickly do a patch release.

3. There are two reason we don’t back port features to the current release branch (right now 2.11):

   1. Because we want patch release to be as thin as possible, and the more changes you make, the more verification we need to do
   2. Adding features in a patch breaks semver.

However, looking at the list of changes for 2.11, we currently have a mix of features that have been merged in. After providing several options and discussing with all the component teams as well as community we came to the conclusion of reverting all feature related changes from 2.11 branch.

What do I need to do?

Please help revert all the commits that are related to new features or enhancements from 2.11 branch that were added after 2.11.0 release.
Here is a rough list of commits that went in after 2.11.0 release for each repo.

Status

Please check-mark one of the below and close this issue once the action item is completed.

• We confirm that no features or enhancements were added to 2.11 branch. We are good to go for 2.11.1 consisting only of bug fixes and security fixes.

OR

• We have reverted all the feature or ehancement related commits from 2.11 branch. We are good to go for 2.11.1 consisting only of bug fixes and security fixes.

Thank you!
cc: @bbarani @CEHENKLE @Divyaasm

This is a component issue for {REPLACE_WITH_RELEASE_VERSION}.
Coming from opensearch-project/opensearch-build#3616. Please follow the following checklist.
Please refer to the DATES in that post.

Preparation

• Assign this issue to a release owner.
• Finalize scope and feature set and update the Public Roadmap.
• All the tasks in this issue have been reviewed by the release owner.
• Create, update, triage and label all features and issues targeted for this release with v__REPLACE_MAJOR_MINOR_PATCH__.

CI/CD

• All code changes for __{REPLACE_MAJOR_MINOR_PATCH}__ are complete.
• Ensure working and passing CI.
• Check that this repo is included in the distribution manifest.

Pre-Release

• Update to the __REPLACE_MAJOR_MINOR__ release branch in the distribution manifest.
• Increment the version on the parent branch to the next development iteration.
• Gather, review and publish release notes following the rules and back port it to the release branch.git-release-notes may be used to generate release notes from your commit history.
• Confirm that all changes for __{REPLACE_MAJOR_MINOR_PATCH}__ have been merged.
• Add this repo to the manifest for the next developer iteration.

Release Testing

• Find/fix bugs using latest tarball and docker image provided in parent release issue and update the release notes if necessary.
• Code Complete: Test within the distribution, ensuring integration, backwards compatibility, and performance tests pass.
• Sanity Testing: Sanity testing and fixing of critical issues found.
• File issues for all intermittent test failures.

Release

• Complete documentation.
• Verify all issued labeled for this release are closed or labelled for the next release.
• Verify the release date mentioned in release notes is correct and matches actual release date.

Post Release

• Prepare for an eventual security fix development iteration by incrementing the version on the release branch to the next eventual patch version.
• Add this repo to the manifest of the next eventual security patch version.
• Suggest improvements to this template.
• Conduct a retrospective, and publish its results.

What is the bug?
{ "statusCode": 403, "error": "Forbidden", "message": "{\n \"status\": 403,\n \"error\": {\n \"type\": \"OpenSearchSecurityException\",\n \"reason\": \"There was internal problem at backend\",\n \"details\": \"no permissions for [cluster:admin/opensearch/ql/datasources/read] and User [name\\u003dtest, backend_roles\\u003d[], requestedTenant\\u003d__user__]\"\n }\n}" }

How can one reproduce the bug?
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

What is the expected behavior?
A clear and concise description of what you expected to happen.

What is your host/environment?

• OS: [e.g. iOS]
• Version [e.g. 22]
• Plugins

Do you have any screenshots?
If applicable, add screenshots to help explain your problem.

Do you have any additional context?
Add any other context about the problem.

This is a tracking issue for phase 1 of OUI theme plugin compliance, which will involve changes to OUI typography and color SASS variables (for both dark and light mode). For full details, including dates and tooling, see opensearch-project/OpenSearch-Dashboards#4291

If your plugin has no UI views or components, please add a comment to that effect, and we'll remove the repo from future look and feel update campaigns.

Actions required

• Acknowledge the issue by adding an assignee who will serve as a point-of-contact
• Provide screenshots and navigation instructions for important views and screens in your plugin or application. This will assist with both manual and automatic validation of compliance
• Identify all typographic properties and styles
• Create issues to mitigate typographic styles not inherited from OUI components or SASS variables
• Identify all color values, including visualization colors and palettes
• Create issues to mitigate typographic styles not inherited from OUI components or SASS variables
• Resolve all mitigation issues
• Validate and test plugin with updated OUI theme

Known issues

• #105

Questions?

Add a comment on opensearch-project/OpenSearch-Dashboards#4291

• Query workbench ppl type uneditable after running any query
  (https://quip-amazon.com/cSY9EAe22jP)
  • Select glue_2 and run any query, like source = default.http_logs | where status = 200 | stats count(status) by clientip, status |head 10
  • UI freezes/can’t edit query after this query returns, either success or error

Is your feature request related to a problem? Please describe.

Since we can write sql query in Query Workbench, and get the result immediately. But we have to paste the sql statement everytime and could not use the result to draw a visualization report.

Describe the solution you'd like

Save the sql query as a type of visualization, so we don't need to save the sql out of opensearch and treat it the same as DQL

Describe alternatives you've considered

This is a component issue for 2.11.0.
Coming from opensearch-project/opensearch-build#3998. Please follow the following checklist.
Please refer to the DATES in that post.

Preparation

• Assign this issue to a release owner.
• Finalize scope and feature set and update the Public Roadmap.
• All the tasks in this issue have been reviewed by the release owner.
• Create, update, triage and label all features and issues targeted for this release with v2.11.0.
• Finalize the code and create the the release branch 2.11.0 from the 2.x branch.

CI/CD

• All code changes for 2.11.0 are complete.
• Ensure working and passing CI.
• Check that this repo is included in the distribution manifest.

Pre-Release

• Increment the version on the parent branch to the next development iteration.
• Gather, review and publish release notes following the rules and back port it to the release branch.git-release-notes may be used to generate release notes from your commit history.
• Confirm that all changes for 2.11.0 have been merged.
• Add this repo to the manifest for the next developer iteration.

Release Testing

• Find/fix bugs using latest tarball and docker image provided in parent release issue and update the release notes if necessary.
• Code Complete: Test within the distribution, ensuring integration, backwards compatibility, and performance tests pass.
• Sanity Testing: Sanity testing and fixing of critical issues found.
• File issues for all intermittent test failures.

Release

• Complete documentation.
• Verify all issued labeled for this release are closed or labelled for the next release.
• Verify the release date mentioned in release notes is correct and matches actual release date.

Post Release

• Prepare for an eventual security fix development iteration by incrementing the version on the release branch to the next eventual patch version.
• Add this repo to the manifest of the next eventual security patch version.
• Suggest improvements to this template.
• Conduct a retrospective, and publish its results.

Describe the bug

The following SQL statements are equivalent, but the workbench will not process the latter and throw an error and say this query is not runnable. If this is solved in later versions, I'll close the issue.

SELECT event_date, event_description FROM events

versus

SELECT 
  event_date, 
  event_description 
FROM events

To Reproduce
Steps to reproduce the behavior:

1. Go to Query Workbench and try two SQL statements structured in the same way as my example.
2. See error

Expected behavior
To insert readable queries.

OpenSearch Version
1.0.0

Dashboards Version
1.0.0

Is your feature request related to a problem?

I am writing PPL to query an index and just display some fields. If I run

source=moviegeek-logs-*

I see fields like trace_id, method, span_id, index

I can run source=moviegeek-logs-* | fields trace_id, span_id, method and get the expected table.

If I add index: source=moviegeek-logs-* | fields trace_id, span_id, method, index I get the following error in the output panel:

Events: Bad Request, this query is not runnable.

1. Is there something special about the "index" field?
2. A better error message here would be invaluable.

What solution would you like?

Better error messaging around syntax and other problems

What alternatives have you considered?

None

Do you have any additional context?

None

Hi All,

This is coming from the campaign here:

• opensearch-project/opensearch-build#3966

Overview

We would like your CI check (specifically plugin build) in GitHub Repo to run on top of the Build Docker Images from production distribution pipeline.

This is to ensure every plugin repo will use the exact docker images we used in Jenkins build, to check their PRs and run tests before merging the code, so that issues can be detected earlier, and environment can be identical across teams.

Solutions

The Build Team has created a simple script to dynamically retrieve the current docker image name/tag, so everyone can easily pull the images for their CI checks.

We have a trial run of the above with k-NN team. The script retrieves the docker image dynamically, save output, and use it as the docker image to pull for the upcoming run:

• opensearch-project/k-NN#1099

Note that GitHub Actions only support LINUX docker container at the time of this writing, so we will add Windows containers later on as well as macOS.

Implementation Notes

We would like you to review above PR and implement similar changes. Note on line 33 of the above k-NN PR, -u and -p parameters needs to assign values accordingly.

• OpenSearch Plugin:

          CI_IMAGE_VERSION=`opensearch-build/docker/ci/get-ci-images.sh -p centos7 -u opensearch -t build | head -1`

• OpenSearch-Dashboards Plugin:

          CI_IMAGE_VERSION=`opensearch-build/docker/ci/get-ci-images.sh -p rockylinux8 -u opensearch-dashboards -t build | head -1`

Note that in the above k-NN PR, despite it being OpenSearch plugin, it still uses rockylinux8, as we initially plan to upgrade to rockylinux. We have since revert back to centos7 to support older versions of systems running k-NN lib. As a result, all OpenSearch plugins still uses centos7 for the time being, and all OpenSearch-Dashboards plugins can go to rockylinux8.

Completion Date

The above should be implemented by Nov. 1, 2023 (2023-11-01) by Plugin Owners to their repository.
And backport the changes to 2.x branch after merging in main branch.

Contacts

Please contact @peterzhuamazon for any questions on this campaign.

cc: @bbarani

Thanks.

This is a component issue for 2.10.0.
Coming from opensearch-project/opensearch-build#3743. Please follow the following checklist.
Please refer to the DATES in that post.

Preparation

• Assign this issue to a release owner.
• Finalize scope and feature set and update the Public Roadmap.
• All the tasks in this issue have been reviewed by the release owner.
• Create, update, triage and label all features and issues targeted for this release with v2.10.0.

CI/CD

• All code changes for 2.10.0 are complete.
• Ensure working and passing CI.
• Check that this repo is included in the distribution manifest.

Pre-Release

• Update to the 2.10.0 release branch in the distribution manifest.
• Increment the version on the parent branch to the next development iteration.
• Gather, review and publish release notes following the rules and back port it to the release branch.git-release-notes may be used to generate release notes from your commit history.
• Confirm that all changes for 2.10.0 have been merged.
• Add this repo to the manifest for the next developer iteration.

Release Testing

• Find/fix bugs using latest tarball and docker image provided in parent release issue and update the release notes if necessary.
• Code Complete: Test within the distribution, ensuring integration, backwards compatibility, and performance tests pass.
• Sanity Testing: Sanity testing and fixing of critical issues found.
• File issues for all intermittent test failures.

Release

• Complete documentation.
• Verify all issued labeled for this release are closed or labelled for the next release.
• Verify the release date mentioned in release notes is correct and matches actual release date.

Post Release

• Prepare for an eventual security fix development iteration by incrementing the version on the release branch to the next eventual patch version.
• Add this repo to the manifest of the next eventual security patch version.
• Suggest improvements to this template.
• Conduct a retrospective, and publish its results.

What is the bug?

Overlapping rows when many tables

How can one reproduce the bug?
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

What is the expected behavior?
A clear and concise description of what you expected to happen.

What is your host/environment?

• OS: [e.g. iOS]
• Version [e.g. 22]
• Plugins

Do you have any screenshots?
If applicable, add screenshots to help explain your problem.

Do you have any additional context?
Add any other context about the problem.

Description

As part of our ongoing efforts to improve the OpenSearch Dashboards' performance, maintainability, and developer experience, we have decided to de-angularize the dashboard.

This change will impact all plugins that use the OpenSearch Dashboard dashboard and require your attention to ensure the compatibility and performance of your plugins. If your plugin has nothing to do with dashboard, please close the issue.

We suggest a thoroughly test of your plugin on new dashboard. Here are some steps:

• Pull this feature branch https://github.com/opensearch-project/OpenSearch-Dashboards/tree/feature/deangular-dashboards.

• Install and start your plugin.

• Run all the tests. Also recommend to do manual tests.

We understand that this transition may require significant work on your part, and we are here to support you during this process. If there is any concerns or issues, feel free to comment here. If there is a bug, please also add it to opensearch-project/OpenSearch-Dashboards#4505.

Received Error: Error building reportsDashboards, retry with: ./build.sh manifests/3.0.0/opensearch-dashboards-3.0.0.yml --component reportsDashboards.
The distribution build for queryWorkbenchDashboards has failed for version: 3.0.0.
Please see build log at https://build.ci.opensearch.org/job/distribution-build-opensearch-dashboards/6753/consoleFull

Describe the bug

GIVEN, I go the the query workbench
AND I run the select query

select * from filebeat-prodapps-2022.10.04 
where container.labels.io_kubernetes_pod_namespace = "xyz"

AND this query gives me multiple results

THEN I expect that the delete query

delete from filebeat-prodapps-2022.10.04 
where container.labels.io_kubernetes_pod_namespace = "xyz"

to delete multiple entries. This is however not the case

To Reproduce
Steps to reproduce the behavior:

1. Go to query workbench
2. run a select query like the one above
3. you should get back multiple results
4. change the select * to delete
5. you likely get an error stating that the query is wrong. This could be because delete is turned off by default
6. if its turned off run
   PUT _plugins/_query/settings { "transient": { "plugins.sql.delete.enabled": "true" } }
7. try again. I expect you get a result like the image above.
   I tested this with 2 different indexes with the same fields

Expected behavior
I expect to get back a delete success with a number of lines that got deleted

OpenSearch Version
I'm running opensearch/dashboards version 2.3.0 via docker compose.

Dashboards Version
2.3.0

Plugins

security, alerting, ML, everyting from the default docker compose

Host/Environment (please complete the following information):

• Ubuntu 20.04
• Firefox 105.0.2

Acceleration flyout refresh interval doesn’t have minutes as an option

This issue might be because we applied a third party js library to highlight the keywords which are taken from some SQL standard but there exists some difference between the other SQL standards and our grammar.

This issue to be transferred to corresponding repository

I am working on launching new light and dark mode themes provided by OUI component library for a target launch within 2.10. These changes support the vision expressed in Future Vision for Dashboards

I have identified the following front end related issues that prevent the theme from appearing complete and potential solutions within this feature:

• When in dark mode, editor appears in light mode

When navigating away from query workbench with an ongoing query, the async polling request will continue to run without a way to cancel

This is a component issue for 2.8.0.
Coming from opensearch-build#3434. Please follow the following checklist.
Please refer to the DATES in that post.

Preparation

• Assign this issue to a release owner.
• Finalize scope and feature set and update the Public Roadmap.
• All the tasks in this issue have been reviewed by the release owner.
• Create, update, triage and label all features and issues targeted for this release with v2.8.0.

CI/CD

• All code changes for 2.8.0 are complete.
• Ensure working and passing CI.
• Check that this repo is included in the distribution manifest.

Pre-Release

• Update to the 2.8 release branch in the distribution manifest.
• Increment the version on the parent branch to the next development iteration.
• Gather, review and publish release notes following the rules and back port it to the release branch.git-release-notes may be used to generate release notes from your commit history.
• Confirm that all changes for 2.8.0 have been merged.
• Add this repo to the manifest for the next developer iteration.

Release Testing

• Find/fix bugs using latest tarball and docker image provided in parent release issue and update the release notes if necessary.
• Code Complete: Test within the distribution, ensuring integration, backwards compatibility, and performance tests pass.
• Sanity Testing: Sanity testing and fixing of critical issues found.
• File issues for all intermittent test failures.

Release

• Complete documentation.
• Verify all issued labeled for this release are closed or labelled for the next release.
• Verify the release date mentioned in release notes is correct and matches actual release date.

Post Release

• Prepare for an eventual security fix development iteration by incrementing the version on the release branch to the next eventual patch version.
• Add this repo to the manifest of the next eventual security patch version.
• Suggest improvements to this template.
• Conduct a retrospective, and publish its results.

Is your feature request related to a problem? Please describe.

Searching through data with ppl is fast, but now I want to view the full document. This is not possible

Describe the solution you'd like

Button to open json/source document like in discover

Describe alternatives you've considered

N/A

Additional context

N/A

If a query is canceled in the query workbench, the status shows as canceled, but it still shows a loading indicator and doesn’t unlock the run button — need to refresh page to continue

Flint Spark extension to create skipping index with OpenSearch which can accelerate query with applicable filtering condition.

Skipping Index

• User can only create, view or delete a skipping index
• One table can only have 1 skipping index for a Flint table
• Name is auto-generated for a given table and follows a pre-defined by a naming convention
• Columns can be accelerated individually using partition, value_set and min_max skipping type
• This is always auto-refreshed or manually refreshed.

Covering Index

• User can only create, view or delete a covering index
• User can have multiple covering index for a Flint table
• User can define their own name for the covering Index
• User can select columns required for creating the covering index
• This is always auto-refreshed or manually refreshed.

Materialized View

• User can only create, view or delete a materialised view
• User can have multiple materialized views for a Flint table
• User can define their own name for the materialized view
• Columns can be aggregated into metrics with different functions like count, min, max, sum and avg.
• The above metrics can be further grouped into different columns [Ex. TUMBLE() or SLIDE()]
• Final check for MVs are where clauses to restrict metrics on a given subset of data
• This is always auto-refreshed or manually refreshed.

Is your feature request related to a problem?
No

What solution would you like?
PPL is currently not supported via Discovery and I would like to have this capability to facilitate the process of interacting with the indices data.

What alternatives have you considered?
I'm currently using Workbench but it doesn't have the same capabilities as Discovery (plugin).

Do you have any additional context?
No

The opensearch-dashboards-functional-test repo is working on upgrading the version of Cypress used in the repo from v9 to v12.

There is a feature branch in the repository called feature/cypress12 to work on the upgrade and ensure that all repositories that have functional tests in the repo can verify that their tests run successfully with the upgraded version of cypress. If any updates to tests are required please submit a PR against the function test repo and base the PR on the feature/cypress12 branch to show the tests running with the upgraded version of Cypress.

Please refer to the migration guide from Cypress to reference when updating tests.

If no work is required to update the tests then please close this issue and indicate that no update is required.

This is a component issue for 2.7.0.
Coming from opensearch-build#3230. Please follow the following checklist.
Please refer to the DATES in that post.

Preparation

• Assign this issue to a release owner.
• Finalize scope and feature set and update the Public Roadmap.
• All the tasks in this issue have been reviewed by the release owner.
• Create, update, triage and label all features and issues targeted for this release with v2.7.0.

CI/CD

• All code changes for 2.7.0 are complete.
• Ensure working and passing CI.
• Check that this repo is included in the distribution manifest.

Pre-Release

• Update to the 2.7 release branch in the distribution manifest.
• Increment the version on the parent branch to the next development iteration.
• Gather, review and publish release notes following the rules and back port it to the release branch.git-release-notes may be used to generate release notes from your commit history.
• Confirm that all changes for 2.7.0 have been merged.
• Add this repo to the manifest for the next developer iteration.

Release Testing

• Find/fix bugs using latest tarball and docker image provided in parent release issue and update the release notes if necessary.
• Code Complete: Test within the distribution, ensuring integration, backwards compatibility, and performance tests pass.
• Sanity Testing: Sanity testing and fixing of critical issues found.
• File issues for all intermittent test failures.

Release

• Complete documentation.
• Verify all issued labeled for this release are closed or labelled for the next release.
• Verify the release date mentioned in release notes is correct and matches actual release date.

Post Release

• Prepare for an eventual security fix development iteration by incrementing the version on the release branch to the next eventual patch version.
• Add this repo to the manifest of the next eventual security patch version.
• Suggest improvements to this template.
• Conduct a retrospective, and publish its results.

Is your feature request related to a problem? Please describe.
In the 'Query Workbench' it would be good if we could active 'Run' (execute search) by pressing Control-Enter (ctrl-enter) key press combo. This is a already used by the 'Dev Tools' feature for example.

Describe the solution you'd like
Pressing Control-Enter (ctrl-enter) key press combo runs the PPL/SQL query

Describe alternatives you've considered
Tabbing to the Run button fails also due to tab inserts in the text field.
Using the mouse does continue to work :-)

Is your feature request related to a problem?
https://forum.opensearch.org/t/shortcut-keys-are-required-when-executing-query-in-query-workbench/11151

What solution would you like?
A clear and concise description of what you want to happen.

What alternatives have you considered?
A clear and concise description of any alternative solutions or features you've considered.

Do you have any additional context?
Add any other context or screenshots about the feature request here.

As part of the discussion around implementing an organization-wide testing policy, I am visiting each repo to see what tests they currently perform. I am conducting this work on GitHub so that it is easy to reference.

Looking at the Dashboards Query Workbench repository, it appears there is

I don't see any requirements for code coverage in the testing documentation. If there are any specific requirements could you respond to this issue to let me know?

If there are any tests I missed or anything you think all repositories in OpenSearch should have for testing please respond to this issue with details.

Describe the bug
Query is not working unless it is written in single line.

To Reproduce
Works fine:

select * from index-logs where body = 'here';

Not working:

select * from index-logs 
where body = 'here';

gives error: no response, this query is not runnable.

Expected behavior
Multi-line query should also work

What is the bug?
SQL workbench doesn't support viewing all values of a child in nested json.

How can one reproduce the bug?
Index a doc with nested objects.

What is the expected behavior?
All the values of the indexed doc, including children objects should be visible in SQL Workbench.

What is your host/environment?
OS/OSD 1.3.0

Do you have any screenshots?
Complete object in Event Analytics

• Check the checkout object in the side panel table
  

• Check the checkout object in results
  

Release Version 2.5.0

This is a component issue for 2.5.0.
Coming from opensearch-build#2908. Please follow the following checklist.
Please refer to the DATES / CAMPAIGNS in that post.

Preparation

• Assign this issue to a release owner.
• Finalize scope and feature set and update the Public Roadmap.
• All the tasks in this issue have been reviewed by the release owner.
• Create, update, triage and label all features and issues targeted for this release with v2.5.0.
• Cut 2.5 branch

CI/CD

• All code changes for 2.5.0 are complete.
• Ensure working and passing CI.
• Check that this repo is included in the distribution manifest.

Pre-Release

• Update to the 2.5.0 release branch in the distribution manifest.
• Increment the version on the parent branch to the next development iteration.
• Gather, review and publish release notes following the rules and back port it to the release branch.git-release-notes may be used to generate release notes from your commit history.
• Confirm that all changes for 2.5.0 have been merged.
• Add this repo to the manifest for the next developer iteration.

Release Testing

• Find/fix bugs using latest tarball and docker image provided in parent release issue and update the release notes if necessary.
• Code Complete: Test within the distribution, ensuring integration, backwards compatibility, and performance tests pass.
• Sanity Testing: Sanity testing and fixing of critical issues found.
• File issues for all intermittent test failures.

Release

• Complete documentation.
• Verify all issued labeled for this release are closed or labelled for the next release.

Post Release

• Prepare for an eventual security fix development iteration by incrementing the version on the release branch to the next eventual patch version.
• Add this repo to the manifest of the next eventual security patch version.
• Suggest improvements to this template.
• Conduct a retrospective, and publish its results.

What is the bug?
Specifically this line failed in cypress run for 2.9.0 https://github.com/opensearch-project/opensearch-dashboards-functional-test/blob/main/cypress/integration/plugins/query-workbench-dashboards/ui.spec.js#L214

Cypress error was expected undefined to be a string. possibly something changed in the API call that broke tests.

Manually verified that download csv and text file are working properly using 2.9.0 RC2.

How can one reproduce the bug?
Steps to reproduce the behavior:
opensearch-project/opensearch-build#3616 (comment)

What is the expected behavior?
A clear and concise description of what you expected to happen.

What is your host/environment?

• OS: [e.g. iOS]
• Version [e.g. 22]
• Plugins

Do you have any screenshots?
If applicable, add screenshots to help explain your problem.

Do you have any additional context?
Add any other context about the problem.

This is a feature request for auto-completion in SQL Workbench. The desired behaviour is to have auto-completion covering the below:

• All SQL keywords ( such as SELECT, FROM, WHERE, GROUP BY etc..)
• Indices and their fields.
• Functions supported by the SQL plugin.

Follow opensearch-project/.github#125 to baseline MAINTAINERS, CODEOWNERS, and external collaborator permissions.

Close this issue when:

1. MAINTAINERS.md has the correct list of project maintainers.
2. CODEOWNERS exists and has the correct list of aliases.
3. Repo permissions only contain individual aliases as collaborators with maintain rights, admin, and triage teams.
4. All other teams are removed from repo permissions.

If this repo's permissions was already baselined, please confirm the above when closing this issue.

This is a component issue for 2.12.0.
Coming from opensearch-project/opensearch-build#4115. Please follow the following checklist.
Please refer to the DATES in that post.

Preparation

• Assign this issue to a release owner.
• Finalize scope and feature set and update the Public Roadmap.
• All the tasks in this issue have been reviewed by the release owner.
• Create, update, triage and label all features and issues targeted for this release with v2.12.0.
• Finalize the code and create the the release branch 2.12 from the 2.x branch.

CI/CD

• All code changes for 2.12.0 are complete.
• Ensure working and passing CI.
• Check that this repo is included in the distribution manifest.

Pre-Release

• Increment the version on the parent branch to the next development iteration.
• Gather, review and publish release notes following the rules and back port it to the release branch.git-release-notes may be used to generate release notes from your commit history.
• Confirm that all changes for 2.12.0 have been merged.
• Add this repo to the manifest for the next developer iteration.

Release Testing

• Find/fix bugs using latest tarball and docker image provided in parent release issue and update the release notes if necessary.
• Code Complete: Test within the distribution, ensuring integration, backwards compatibility, and performance tests pass.
• Sanity Testing: Sanity testing and fixing of critical issues found.
• File issues for all intermittent test failures.

Release

• Complete documentation.
• Verify all issued labeled for this release are closed or labelled for the next release.
• Verify the release date mentioned in release notes is correct and matches actual release date.

Post Release

• Prepare for an eventual security fix development iteration by incrementing the version on the release branch to the next eventual patch version.
• Add this repo to the manifest of the next eventual security patch version.
• Suggest improvements to this template.
• Conduct a retrospective, and publish its results.

Describe the bug
Having an Object with the following structure:
MyData
{
name: String
body: MyBody
}
MyBody
{
sex: String
}

If I create the index with the following mappings
mappings": {
"properties": {
"body": { "type": "object", "enabled": false }
}
}

Executing the query from the Dashboard "select * from my_index_test;" I got the error "[IllegalStateException] There was internal problem at backend, this query is not runnable."

But the index works fine, because inserting and searching documents using the Java high-level REST client, I managed to get the documents and the body field is not getting indexed.

To Reproduce
Java code:
CreateIndexRequest createIndexRequest = new CreateIndexRequest("my_index_test");
HashMap<String, String> typeMapping = new HashMap<String,String>();
typeMapping.put("type", "object");
typeMapping.put("enabled", "false");
excludeObjectsMapping.put("body", typeMapping);
HashMap<String, Object> mapping = new HashMap<String, Object>();
mapping.put("properties", excludeObjectsMapping);
createIndexRequest.mapping(mapping);
searchClient.indices().create(createIndexRequest, RequestOptions.DEFAULT);

1. Go to 'OpenSearch Dashboards'
2. Click on 'Query Workbench'
3. select * from my_index_test;
4. See error

Expected behavior
No errors shoud be shown

OpenSearch Version
1.2.0

Dashboards Version
1.2.0

Host/Environment (please complete the following information):

• OS: Linux
• Browser and version Chrome 100.0.4896.8

Update 1:
executing the query "select name from my_index_test" it works, so the problem is that select (*), also include the "body" field which is not indexd.

Thank you.
Michele