opensearch-project/opensearch-benchmark-workloads

[BUG] Unused search operations in the nyc_taxis workload

Open

#67 opened on Mar 21, 2023

View on GitHubContributor guide
 (1 comment) (0 reactions) (1 assignee)Python (137 forks)auto 404
Low Prioritybuggood first issue

Repository metrics

Stars
 (33 stars)
PR merge metrics
 (PR metrics pending)

Description

What is the bug?

The 'nyc_taxis' workload contains the following search operations (defined here).

  1. default
  2. range
  3. distance_amount_agg
  4. autohisto_agg
  5. date_histogram_agg
  6. date_histogram_calendar_interval
  7. date_histogram_calendar_interval_with_tz
  8. date_histogram_fixed_interval
  9. date_histogram_fixed_interval_with_tz
  10. date_histogram_fixed_interval_with_metrics
  11. auto_date_histogram
  12. auto_date_histogram_with_tz
  13. auto_date_histogram_with_metrics

Out of these, only 1–5 are being used in a test-procedure (append-no-conflicts) while they remaining are not mapped to any test-procedure (defined here). This reduces our coverage for 'aggregation' queries.

It appears that the 'date-histogram' test-procedure that executed these unmapped operations was incorrectly removed in https://github.com/opensearch-project/opensearch-benchmark-workloads/commit/cba4e45dda37ac03abbd3c9dd4532475dac355e9, thinking it was part of X-pack code, which it wasn't.

What is the expected behavior?

The missing test-procedure should be added back. I have confirmed that these operations execute successfully on open-source OpenSearch.

What is your host/environment?

Ubuntu 22.04.2 LTS (GNU/Linux 5.15.0-1031-aws x86_64) opensearch-benchmark 0.2.0

Contributor guide

Research direction
Identify the commit that removed the date histogram test procedure (cba4e45dda37ac03abbd3c9dd4532475dac355e9) and restore it to map the unused search operations 6-13. Ensure it aligns with the current workload structure.
Tech stack
python
Domain
backendtesting
Issue type
Test
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
2
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-3 hours
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
None
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
65