opensearch-sugar 1.0.0

data/adrs/ADR-004-integration-tests-no-mocking.md

@@ -0,0 +1,91 @@
+# ADR-004: Integration Tests Against a Real OpenSearch Node; No HTTP Mocking
+
+## Status
+
+Accepted
+
+## Date
+
+2026-04-28
+
+## Context
+
+`opensearch-sugar` wraps the OpenSearch HTTP API. Its correctness depends on real
+request/response semantics: field ordering in bodies, HTTP status codes, error shapes,
+and side effects (index creation, document persistence, model deployment state). The question
+is whether tests should run against a live cluster or use some form of HTTP-level mocking.
+
+The main options evaluated were:
+
+- **VCR (cassette recording)**: record real HTTP interactions once, replay from cassettes in CI
+- **WebMock / stub_request**: hand-write HTTP stubs for each tested scenario
+- **Live integration tests with a Dockerized OpenSearch node**: run all tests against a real
+  cluster spun up via `docker compose`
+
+## Decision
+
+All tests are integration tests that run against a live OpenSearch node. There is no mocking
+layer. A `docker compose up -d` brings up the cluster before running `bundle exec rspec`.
+
+```bash
+# Start the cluster
+docker compose up -d
+
+# Run the full suite
+bundle exec rspec
+```
+
+Tests are responsible for cleaning up their own fixtures (indexes, models, pipelines) and must
+not leave traces in the cluster after they complete.
+
+VCR was explicitly evaluated and rejected.
+
+## Consequences
+
+### Positive
+
+- **High fidelity**: tests exercise the actual HTTP client, auth, TLS, serialization, and
+  OpenSearch response parsing — the exact code paths that matter in production.
+- **No cassette maintenance**: recorded cassettes drift as the OpenSearch API evolves; with live
+  tests there is nothing to regenerate or keep in sync.
+- **Catches real regressions**: version bumps of `opensearch-ruby` or OpenSearch itself are
+  immediately visible in the test results.
+- **Simple setup**: `docker compose up -d && bundle exec rspec` is the entire test workflow;
+  no cassette directory, no VCR configuration, no per-test recording modes.
+
+### Negative
+
+- **Requires Docker**: contributors without Docker cannot run the suite locally without
+  additional setup.
+- **Slower than mocked tests**: the suite waits for network I/O and OpenSearch processing;
+  ML model deployment tests are particularly slow due to polling.
+- **Flakiness risk**: tests are sensitive to cluster state. Poorly isolated tests can interfere
+  with each other if cleanup is missed.
+- **No offline CI without a real cluster**: CI pipelines must be able to start a Docker service
+  container; environments that cannot do so cannot run the suite.
+
+### Neutral
+
+- Unit tests for pure Ruby logic (no I/O) are welcome alongside integration tests. If logic
+  that can be tested in isolation is added to `lib/`, unit specs should be added as well.
+- The `spec/env.testing` file (loaded via `dotenv`) supplies cluster credentials; this file
+  must not be committed with production credentials.
+
+## Alternatives Considered
+
+**VCR (cassette recording)**
+Evaluated and rejected. VCR adds complexity (cassette storage, recording modes, sensitive-data
+filtering) without sufficient benefit for this gem. The core value of these tests is verifying
+real interactions with OpenSearch; replaying stale cassettes undermines that value and creates
+a maintenance burden.
+
+**WebMock / hand-written stubs**
+Rejected for the same reasons: stubs are approximations of the real API and would require
+manual updates whenever the response shape changes. For a thin wrapper gem, testing against
+the real thing is more reliable than maintaining an approximate fake.
+
+## Documentation Requirements
+
+- The README and CONTRIBUTING guide must document the Docker prerequisite and the
+  `docker compose up -d` + `bundle exec rspec` workflow.
+- The `spec/env.testing` file must document all required environment variables.

data/adrs/ADR-005-exceptions-over-result-objects.md

@@ -0,0 +1,107 @@
+# ADR-005: Exceptions for Error Handling; No Result/Either Objects
+
+## Status
+
+Accepted
+
+## Date
+
+2026-04-28
+
+## Context
+
+When a Sugar method fails — invalid arguments, OpenSearch returns an error, a multi-step
+sequence partially succeeds — the gem must communicate that failure to the caller. Two broad
+approaches were considered:
+
+- **Exceptions**: raise a Ruby exception; callers use `begin/rescue` to handle errors
+- **Result/Either objects**: return a value that is either a success wrapper or a failure
+  wrapper, forcing callers to inspect the return value (e.g., `result.success?`,
+  `result.value`, `result.error`)
+
+The Result pattern (sometimes called Dry::Monads `Result`, `Either`, or a custom `Ok`/`Err`
+type) is popular in functional-leaning Ruby code. Before settling on exceptions, a full
+comparison of what the codebase would look like under each approach was produced and reviewed.
+
+## Decision
+
+We use Ruby exceptions for all error handling. Sugar raises `OpenSearch::Sugar::Error` (or a
+more specific subclass) for errors that originate within the gem; errors from the underlying
+`opensearch-ruby` transport layer are allowed to propagate as-is (i.e., as
+`OpenSearch::Transport::Transport::Error` subclasses).
+
+```ruby
+# Sugar raises on failure
+begin
+  index = client.open_or_create_index("my_index")
+  index.update_settings(settings)
+rescue OpenSearch::Sugar::Error => e
+  # Sugar-level error (e.g., invalid arguments, sequence failure)
+  logger.error("Sugar error: #{e.message}")
+rescue OpenSearch::Transport::Transport::Error => e
+  # Raw transport error (e.g., connection refused, 4xx/5xx from OpenSearch)
+  logger.error("OpenSearch error: #{e.message}")
+end
+
+# Methods that succeed simply return the result; no wrapper needed
+count = index.count        # Integer
+settings = index.settings  # Hash
+```
+
+The Result pattern was considered and summarized in full detail, but not adopted.
+
+## Consequences
+
+### Positive
+
+- **Idiomatic Ruby**: exceptions are the standard Ruby error-handling mechanism; contributors
+  and users familiar with Ruby (or any Ruby gem) will immediately understand the contract.
+- **Clean happy path**: methods return their values directly with no wrapping. Callers that
+  don't care about errors don't need to unwrap anything.
+- **Chainable interfaces**: because successful methods return their natural value (an `Index`,
+  an `Integer`, a `Hash`) rather than a `Result` wrapper, return values can be used directly
+  in chains and compositions without a prior unwrapping step. For example,
+  `client.open_or_create_index("my_index").update_settings(settings)` works naturally. With
+  `Result` objects, each step would require unwrapping before the next call.
+- **No new dependencies**: Result types would require either `dry-monads` or a custom
+  implementation. Exceptions are built into the language.
+- **Interoperability**: code that mixes Sugar calls with other Ruby libraries doesn't need
+  an adapter layer to convert `Result` values to exceptions or vice versa.
+
+### Negative
+
+- **Errors are invisible in signatures**: a method's return type doesn't communicate what it
+  can raise. Callers must read documentation or source to know which exceptions to handle.
+- **Easy to ignore**: unlike a `Result` type, exceptions can be silently swallowed by an
+  overly broad `rescue Exception` or `rescue StandardError` in the caller's code.
+- **No enforced handling**: a compiler/type checker cannot require the caller to handle the
+  error case (unlike `Result` in Rust or Haskell). Ruby's type system provides no enforcement.
+
+### Neutral
+
+- `OpenSearch::Sugar::Error < StandardError` is the base error class for all Sugar-originated
+  exceptions. More specific subclasses should be introduced as distinct error categories emerge.
+- Errors from the raw `opensearch-ruby` client propagate unchanged. Sugar does not wrap or
+  re-raise transport exceptions except in cases where it needs to add context.
+- The Result pattern summary produced during evaluation is preserved in `vibe/` as a reference
+  for contributors who want to understand the tradeoff in detail.
+
+## Alternatives Considered
+
+**Result/Either objects (e.g., `dry-monads`)**
+Evaluated in full. Rejected because:
+- It adds a `dry-monads` dependency (or requires a custom implementation) to a gem that
+  otherwise has minimal dependencies.
+- It forces callers to adopt a monadic style that is not idiomatic in most Ruby codebases,
+  especially non-Rails ones.
+- The happy-path ergonomics worsen: every return value must be unwrapped before use.
+- `opensearch-ruby` itself raises exceptions, so callers would still need `rescue` for
+  transport errors; mixing `Result` and exceptions produces an inconsistent interface.
+
+## Documentation Requirements
+
+- REFERENCE must document `OpenSearch::Sugar::Error` and any subclasses with their meanings.
+- HOWTO must include an error-handling section showing the recommended `rescue` pattern for
+  both Sugar errors and raw transport errors.
+- EXPLANATION should note that Result objects were considered and explain the rationale for
+  choosing exceptions.

data/adrs/ADR-006-ssl-on-by-default.md

@@ -0,0 +1,95 @@
+# ADR-006: SSL Enabled by Default; Explicit Opt-Out for Development
+
+## Status
+
+Accepted
+
+## Date
+
+2026-04-28
+
+## Context
+
+`OpenSearch::Sugar::Client` wraps `OpenSearch::Client` and must decide what default transport
+security settings to apply when the caller does not specify them. OpenSearch clusters in
+production are almost universally deployed with TLS. The risk of accidentally connecting
+without TLS — exposing credentials or data in transit — is meaningful and asymmetric: the
+cost of a misconfigured production cluster far outweighs the minor inconvenience of explicitly
+disabling SSL for local development.
+
+The two realistic positions are:
+
+1. **SSL off by default, opt-in for production** — easy local setup, but a forgotten
+   production configuration is a silent security failure.
+2. **SSL on by default, explicit opt-out for development** — requires one extra line in
+   development, but the default is always secure.
+
+## Decision
+
+SSL is enabled by default. Callers who need to connect to a development cluster without
+certificate verification must explicitly pass `ssl: { verify: false }` in transport options.
+
+```ruby
+# Production — SSL on, certificate verified (default; no extra config needed)
+client = OpenSearch::Sugar::Client.new(
+  host: "https://search.production.example.com:9200",
+  user: ENV["OPENSEARCH_USER"],
+  password: ENV["OPENSEARCH_PASSWORD"]
+)
+
+# Development — SSL on but verification disabled
+client = OpenSearch::Sugar::Client.new(
+  host: "https://localhost:9200",
+  user: "admin",
+  password: ENV["OPENSEARCH_PASSWORD"],
+  transport_options: {
+    ssl: { verify: false }
+  }
+)
+```
+
+Documentation leads with the production-safe form and explicitly explains how to disable
+verification for development. The Docker Compose test environment uses `ssl: { verify: false }`
+in `spec/env.testing`.
+
+## Consequences
+
+### Positive
+
+- **Secure by default**: a caller who copies the simplest example from the README will get
+  a TLS-secured connection. There is no "forgot to enable SSL in prod" failure mode.
+- **Explicit intent in dev code**: `ssl: { verify: false }` in development configuration
+  is a visible, searchable signal that certificate verification is intentionally disabled.
+  Code review can flag it if it appears in production configuration.
+
+### Negative
+
+- **Friction for local development**: first-time setup requires understanding why the default
+  connection attempt to a local Docker cluster fails and how to disable verification. Without
+  clear documentation this is confusing.
+- **No plaintext (`http://`) shortcut**: callers who want plain HTTP (no TLS at all) must
+  also configure transport options explicitly. The documentation must cover this case.
+
+### Neutral
+
+- The underlying `OpenSearch::Client` and the `Faraday` HTTP adapter handle the actual TLS
+  negotiation; Sugar does not implement TLS logic itself.
+- Credentials must always be provided via environment variables (e.g., loaded from
+  `spec/env.testing` with `dotenv`); hardcoding passwords in source is never acceptable
+  regardless of environment.
+
+## Alternatives Considered
+
+**SSL off by default**
+Rejected. The security asymmetry is clear: forgetting to enable SSL in production is a serious
+vulnerability with no automatic safeguard. Forgetting to disable SSL verification in development
+is a minor inconvenience that produces a loud, obvious error.
+
+## Documentation Requirements
+
+- README must include both the production (SSL on) and development (verify: false) connection
+  examples, with a prominent note that `verify: false` is for development only.
+- HOWTO "Connection and Configuration" section must appear at the top of the guide and cover
+  both cases.
+- EXPLANATION must explain why SSL is on by default and what `verify: false` does (and does
+  not) protect against.

data/adrs/ADR-007-selective-sugar-surface.md

@@ -0,0 +1,118 @@
+# ADR-007: Selective Sugar Surface — Intentionally Incomplete API Coverage
+
+## Status
+
+Accepted
+
+## Date
+
+2026-04-28
+
+## Context
+
+`opensearch-sugar` is a convenience wrapper, not a complete replacement for `opensearch-ruby`.
+The OpenSearch HTTP API is large and continues to grow: document CRUD, search, aggregations,
+bulk operations, cluster management, snapshots, ingest pipelines, ML Commons, and more.
+
+Two approaches to API coverage were considered:
+
+1. **Comprehensive wrapping**: provide Sugar methods for every (or nearly every) OpenSearch
+   operation, so callers never need to call the raw client.
+2. **Selective wrapping**: provide Sugar methods only for operations that genuinely benefit
+   from a higher-level interface (multi-step sequences, complex defaults, common boilerplate).
+   For everything else, rely on `SimpleDelegator` to pass calls through to the raw
+   `OpenSearch::Client` transparently.
+
+## Decision
+
+Sugar wraps only operations where a higher-level interface provides meaningful value:
+
+- **Multi-step sequences** that would otherwise be error-prone (e.g., close/update/reopen
+  for settings changes — see ADR-002)
+- **Lifecycle management** that requires orchestration (e.g., model registration and
+  deployment — see ADR-003)
+- **Common index management boilerplate** (`open_or_create_index`, `has_index?`, `index_names`)
+- **Text analysis helpers** (`test_analyzer_by_name`, `test_analyzer_by_fieldname`, `test_analyzer_by_definition`)
+
+Document CRUD, search, bulk operations, aggregations, and cluster management are intentionally
+left as raw-client operations:
+
+```ruby
+# Sugar — meaningful abstraction
+index = client.open_or_create_index("products")
+index.update_settings(settings)          # hides close/reopen
+index.count                              # hides query body construction
+model = client.models.register(...)      # hides polling loop
+
+# Delegation — use the raw client directly
+client.index(index: "products", body: doc)        # no benefit to wrapping
+client.search(index: "products", body: query)     # DSL is already expressive
+client.bulk(body: operations)                     # no benefit to wrapping
+client.cluster.health                             # no benefit to wrapping
+```
+
+This is an explicit design choice, not an omission. The guiding principle:
+> **"Use sugar where you want it, raw client where you need it."**
+
+## Consequences
+
+### Positive
+
+- **Maintenance stays manageable**: every Sugar method is a liability that must be kept in
+  sync with the OpenSearch API. Wrapping only what adds value keeps the surface small.
+- **Full API always accessible**: because `Sugar::Client` uses `SimpleDelegator` (ADR-001),
+  callers are never blocked by a missing Sugar method; the full raw API is always one call
+  away.
+- **Avoids redundant abstraction**: wrapping `client.search` into a Sugar method would not
+  simplify anything — the OpenSearch query DSL is already a well-documented, expressive
+  interface.
+- **Clearer mental model**: callers learn which operations benefit from Sugar and which don't,
+  rather than hunting for Sugar wrappers that don't exist or produce no benefit.
+
+### Negative
+
+- **Callers must know the raw client API**: for operations without Sugar equivalents, callers
+  need to read `opensearch-ruby` documentation. Sugar does not hide this complexity.
+- **Inconsistent abstraction level**: some operations are "high-level Sugar" and others are
+  "raw client" in the same code. This boundary can feel arbitrary to new contributors.
+- **No guided discovery for raw operations**: there is no machine-readable declaration of
+  which operations are delegated vs. implemented; callers discover this through docs or
+  source inspection.
+
+### Neutral
+
+- The `old_docs/DELEGATED_METHODS_ANALYSIS.md` file documents 19 specific examples of raw
+  client calls used in the HOWTO guide and categorizes which have Sugar alternatives.
+- New Sugar methods should be added only when they hide genuine complexity. A "thin wrapper
+  that just passes arguments through" should not be added.
+- The boundary will shift over time as new use cases emerge. Revisit this ADR before adding
+  Sugar methods for document CRUD or basic search.
+
+## Alternatives Considered
+
+**Comprehensive wrapping**
+Rejected. A comprehensive wrapper would need to track every OpenSearch API change, producing
+a large maintenance surface and introducing lag between upstream API additions and Sugar
+availability. It would also need to either replicate the entire query DSL (impractical) or
+provide a lossy subset of it (worse than the raw API).
+
+## Diagram
+
+```mermaid
+flowchart LR
+    Caller --> SugarClient["Sugar::Client"]
+
+    SugarClient -->|"Sugar method\n(adds value)"| SugarImpl["Sugar implementation\n(open_or_create, update_settings,\nmodels.register, ...)"]
+    SugarClient -->|"Delegated\n(no wrapping needed)"| RawClient["OpenSearch::Client\n(search, index, bulk,\ncluster.health, ...)"]
+
+    SugarImpl --> RawClient
+```
+
+## Documentation Requirements
+
+- HOWTO must demonstrate both Sugar methods and delegated raw-client calls side by side,
+  making clear which is which.
+- EXPLANATION must articulate the "use sugar where you want it, raw client where you need it"
+  philosophy and explain why document CRUD and search are intentionally unwrapped.
+- The `DELEGATED_METHODS_ANALYSIS.md` analysis in `old_docs/` should be kept or migrated to
+  an appropriate location as a reference for which operations are and are not wrapped.

data/adrs/ADR-008-integration-test-design.md

@@ -0,0 +1,178 @@
+# ADR-008: Integration Test Design
+
+## Status
+
+Accepted
+
+## Date
+
+2026-04-28
+
+## Context
+
+Having established in ADR-004 that all tests run against a live OpenSearch node with no HTTP
+mocking, this ADR records the specific structural and scoping decisions made when designing
+the integration test suite for `opensearch-sugar`.
+
+The key questions were:
+- How to organize spec files (per class vs. per feature)
+- How to isolate tests from each other
+- How to handle slow ML model tests
+- How to share the client setup across specs
+- What Sugar-owned behavior is in scope vs. what is delegated and therefore out of scope
+- What to do about unimplemented stub methods (`index_document`, `index_jsonl_file`)
+
+## Decision
+
+### File organization: per feature, not per class
+
+Spec files are organized by feature cluster rather than by class. The `Client` and `Index`
+classes are large enough that a single file per class would become unwieldy. Feature-based
+files are independently runnable via `--pattern` and keep each file focused on one concern
+with its own setup.
+
+```
+spec/
+  support/
+    opensearch_client.rb        # shared client setup helper
+  opensearch/sugar/
+    client/
+      connection_spec.rb        # ping, raw_client type
+      index_management_spec.rb  # has_index?, index_names, open_or_create, []
+      settings_spec.rb          # update_settings (cluster-level settings)
+    index/
+      lifecycle_spec.rb         # Index.open, Index.create, delete!
+      document_spec.rb          # count, clear!, delete_by_id, index_document, index_jsonl_file
+      settings_spec.rb          # settings, update_settings (index-level)
+      mappings_spec.rb          # mappings, update_mappings
+      aliases_spec.rb           # aliases, create_alias
+      analyzer_spec.rb          # all_available_analyzers, test_analyzer_by_name, test_analyzer_by_fieldname, test_analyzer_by_definition
+    models/                     # tagged :slow, :models — excluded from default run
+      registration_spec.rb
+      lookup_spec.rb
+      lifecycle_spec.rb
+      pipeline_spec.rb
+```
+
+### Test isolation
+
+Each spec that creates an index uses a uniquely named index per example:
+
+```ruby
+let(:index_name) { "sugar_test_#{SecureRandom.hex(6)}" }
+```
+
+Cleanup is registered with an `after` hook:
+
+```ruby
+after { client.indices.delete(index: index_name) rescue nil }
+```
+
+The `rescue nil` is intentional: if a test fails before the index is created, cleanup must
+not itself raise. No global sweep is used.
+
+### No raw OpenSearch::Client in specs
+
+Specs interact exclusively through `OpenSearch::Sugar::Client`. No test may call
+`OpenSearch::Client` directly. This keeps specs honest about what Sugar provides vs. what
+would require bypassing the abstraction.
+
+### Shared client setup
+
+A `spec/support/opensearch_client.rb` helper loads `spec/env.testing` via `dotenv` and
+defines an RSpec shared context that exposes `let(:client)`. Every spec file includes this
+shared context. The client is configured for the local Docker cluster with SSL verification
+disabled.
+
+### ML model tests: tagged and excluded by default
+
+All specs in `spec/opensearch/sugar/models/` are tagged `:slow` and `:models`. They are
+excluded from the default `bundle exec rspec` run via RSpec filter configuration. To run
+them:
+
+```bash
+bundle exec rspec --tag models
+```
+
+### Scope: Sugar-owned behavior only
+
+Tests cover only behavior implemented by Sugar. Delegated methods (e.g., `client.search`,
+`client.index`, `client.bulk`) are not tested — `opensearch-ruby` is responsible for those.
+
+The guiding question for inclusion: *"Does Sugar add logic here, or is it a straight
+pass-through to the underlying client?"*
+
+### `update_settings` and `update_mappings` raise on failure
+
+The existing implementation returns an error Hash on failure, which is inconsistent with
+ADR-005. As part of this work, both methods are changed to raise `OpenSearch::Sugar::Error`
+on failure (after attempting to reopen the index). This is a breaking change from the
+previous behavior.
+
+### `index_document` and `index_jsonl_file`
+
+Both stub methods are implemented as simple, intentionally inefficient implementations
+suitable for small-scale and testing use only. A TODO is left in the code for a future
+bulk-API implementation.
+
+```ruby
+# index_document: requires both arguments
+def index_document(doc, id)
+  # TODO: inefficient; replace with bulk API for large-scale use
+  client.index(index: name, id: id, body: doc)
+end
+
+# index_jsonl_file: accepts a String path or any IO-like object (StringIO, File)
+def index_jsonl_file(source, id_field:)
+  # TODO: inefficient; replace with bulk API for large-scale use
+  io = source.is_a?(String) ? File.open(source) : source
+  io.each_line do |line|
+    doc = JSON.parse(line, symbolize_names: true)
+    id = doc.fetch(id_field.to_sym) {
+      raise ArgumentError, "id_field :#{id_field} not found in document"
+    }
+    index_document(doc, id.to_s)
+  end
+end
+```
+
+Specs for these methods use `StringIO` to avoid filesystem dependencies.
+
+## Consequences
+
+### Positive
+
+- Feature-based files are independently runnable and focused
+- Unique index names eliminate inter-test interference without a global sweep
+- ML tests are opt-in; default suite runs fast
+- Restricting specs to Sugar's API surface keeps the test suite honest
+- Implementing the stubs closes a gap in the public API and gives tests something real to run against
+
+### Negative
+
+- `update_settings`/`update_mappings` behavior change (raise vs. return Hash) is breaking for
+  any existing callers relying on checking `result[:status]`
+- `index_document` and `index_jsonl_file` are explicitly not production-grade; callers doing
+  bulk loads must use the raw `client.bulk` API until a proper bulk implementation is added
+
+### Neutral
+
+- `spec/env.testing` must not be committed with real credentials; `.gitignore` covers it
+- The `spec/opensearch/sugar_spec.rb` skeleton (with wrong constant casing and a hardcoded
+  failure) is deleted and replaced by the new structure
+
+## Alternatives Considered
+
+**Per-class spec files**
+Considered and rejected; the `Client` and `Index` classes are large enough that single-file
+specs would become hard to navigate and run selectively.
+
+**Global `after(:suite)` sweep to delete all `sugar_test_*` indexes**
+Considered as a safety net. Rejected as primary strategy in favor of per-example cleanup,
+which makes cleanup intent explicit. A sweep could be added as a belt-and-suspenders measure
+in the future.
+
+## Documentation Requirements
+
+- `CONTRIBUTING` guide must document the `:models` tag and how to run ML tests.
+- `spec/env.testing` must document all required environment variables inline.

data/compose.yml

@@ -0,0 +1,2 @@
+include:
+  - compose_opensearch.yml

data/compose_opensearch.yml

@@ -0,0 +1,31 @@
+services:
+  dor-opensearch:
+    image: opensearchproject/opensearch:latest
+    container_name: opensearch-opensearch-sugar
+    environment:
+      - cluster.name=opensearch
+      - node.name=opensearch-node
+      - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m"
+      - discovery.type=single-node
+    env_file:
+      - spec/docker/env.development
+    ulimits:
+      memlock:
+        soft: -1
+        hard: -1
+      nofile:
+        soft: 65536
+        hard: 65536
+    volumes:
+      - opensearch-data1:/usr/share/opensearch/data
+    ports:
+      - 29200:9200 # REST API
+      - 29600:9600 # Performance Analyzer
+    networks:
+      - opensearch-net
+
+volumes:
+  opensearch-data1:
+
+networks:
+  opensearch-net: