Manticore Search

Overview

Manticore Search is an open-source full-text search engine. This template deploys a replicated Manticore cluster using Galera replication, together with an orchestrator that performs coordinated, zero-downtime CSV imports from an S3 bucket into every replica, optional scheduled backups to S3, and a web dashboard for cluster operations. It is built for datasets that are regenerated upstream and republished as CSV: data arrives in a bucket, and the orchestrator turns it into a distributed table that keeps serving searches while it is reloaded.

This template deploys into an existing GVC that you already have. It does not create or manage a GVC.

What Gets Created

Resource	Name	Purpose	Optional
Workload	`RELEASE_NAME-manticore`	Manticore `searchd` cluster (stateful, 3 replicas by default); each replica also runs an `agent` sidecar for local table operations	—
Workload	`RELEASE_NAME-orchestrator-api`	REST API coordinating cluster-wide init, import, repair, backup and restore (standard, 2 replicas by default)	—
Workload	`RELEASE_NAME-orchestrator-job`	Cron job that runs the configured `init`, `import`, `health` or `repair` action; ships suspended and is triggered on demand	—
Workload	`RELEASE_NAME-ui`	Management dashboard (standard, 1 replica, internal-only by default)	—
Volume set	`RELEASE_NAME-manticore-vs`	Per-replica data volume for indexes and cluster state (200 GB by default)	—
Volume set	`RELEASE_NAME-manticore-vs-shared`	Shared volume used to hand import artifacts from the job to the replicas (100 GB by default)	—
Secrets	`RELEASE_NAME-manticore-config`, `RELEASE_NAME-manticore-schema`, `RELEASE_NAME-manticore-startup`	`searchd` base configuration, table schema registry, startup script	—
Identities	`RELEASE_NAME-manticore-identity`, `RELEASE_NAME-manticore-orchestrator-identity`, `RELEASE_NAME-manticore-orchestrator-job-identity`	S3 access through your cloud account and secret access for each tier	—
Policies	`RELEASE_NAME-manticore-config-policy`, `RELEASE_NAME-manticore-exec-policy`, `RELEASE_NAME-manticore-orchestrator-policy`	`reveal` on the three config secrets and your agent-token secret; the right to start the cron job and read the cluster workload	—
Workload	`RELEASE_NAME-manticore-backup`	Cron job performing logical backups to a separate S3 bucket, with its own identity and policy	`orchestrator.backup.enabled: true`
Workloads	`RELEASE_NAME-load-test`, `RELEASE_NAME-load-test-controller`	k6 load-test runner and the cron controller that scales it up and back to zero	`loadTest.enabled: true`
Secret	`RELEASE_NAME-manticore-k6-script`	Generated k6 test script	`loadTest.enabled: true`
Domain	your `domain.name`	Routes `/api/*` to the orchestrator API and everything else to the UI	`domain.enabled: true`

Prerequisites

Two things must exist before you install: the agent-token secret and the S3 source bucket with a cloud account that can read it. Only AWS S3 is supported.

Create the agent-token secret

The orchestrator, the agent sidecars and the UI authenticate to each other with one bearer token, stored in an opaque secret you create:

printf '%s' "$(openssl rand -hex 32)" | cpln secret create-opaque --name SECRET_NAME --encoding plain -f -

Set orchestrator.agent.tokenSecretName to this name.

If the secret does not exist at install time, the deployment wedges silently: the containers never start, cpln logs returns nothing, and the only place the missing secret is named is status.versions[].message:

cpln workload get-deployments RELEASE_NAME-manticore --gvc GVC_NAME -o yaml

Create the secret and the deployment recovers on its own; to skip the wait, run cpln workload force-redeployment RELEASE_NAME-manticore --gvc GVC_NAME.

Create the source bucket and a read-only IAM policy

Create an S3 bucket and upload your CSV files (for example to imports/addresses.csv). Imports only ever read from this bucket — every scratch artifact is written to the shared volume — so a read-only policy is sufficient. Create an IAM policy with the following JSON, replacing my-manticore-bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket", "s3:GetBucketLocation"],
      "Resource": "arn:aws:s3:::my-manticore-bucket"
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-manticore-bucket/*"
    }
  ]
}

Set buckets.sourceBucket to the bucket name and buckets.awsRegion to its region.

Create a cloud account and reference the policy

Create a Control Plane cloud account for your AWS account by following the Create a Cloud Account guide, and attach the policy above to the role it uses. Set buckets.cloudAccountName to the cloud account name and buckets.awsPolicyRefs to the policy name. Custom policies are named without a prefix; only AWS-managed policies take the aws:: prefix (for example aws::AmazonS3ReadOnlyAccess).

Scheduled backups need a second, writable bucket with its own policy and cloud account. That setup is optional and described under Backing Up.

Installation

Install from the marketplace registry into your existing GVC, naming the agent-token secret and the source-bucket resources you created above:

cpln helm install RELEASE_NAME oci://ghcr.io/controlplane-com/templates/manticore \
  --version 2.2.0 --gvc GVC_NAME \
  --set orchestrator.agent.tokenSecretName=SECRET_NAME \
  --set buckets.cloudAccountName=CLOUD_ACCOUNT_NAME \
  --set buckets.awsPolicyRefs[0]=POLICY_NAME \
  --set buckets.sourceBucket=BUCKET_NAME

The default tables value defines one example table, addresses, read from imports/addresses.csv. Define your own tables in a values file (see Tables) and pass it with -f as described in the CLI installation guide.

UI

Browse, install, and manage templates visually

CLI

Manage templates from your terminal

Terraform

Declare templates in your Terraform configurations

Pulumi

Declare templates in your Pulumi programs

Configuration

Buckets

buckets:
  cloudAccountName: my-manticore-cloudaccount    # Name of your configured Cloud Account
  awsPolicyRefs:                        # IAM policies for S3 access
    - my-manticore-policy       # Note: if using a custom policy, omit the aws:: prefix as this is only for AWS managed policies
  awsRegion: us-east-1                  # Region of your S3 bucket
  sourceBucket: my-manticore-bucket               # S3 bucket containing files to import

Tables

One entry per searchable table. csvPath is a path within buckets.sourceBucket, or a list of paths for a multi-segment table.

tables:
  - name: addresses
    csvPath:
      - imports/addresses.csv
    config:
      haStrategy: noerrors        # Distributed-query HA strategy; noerrors skips agents returning errors
      agentRetryCount: 3          # Retries for a failed agent connection
      clusterMain: false          # true replicates the main table across all nodes
      segmentCount: 1             # Must equal the number of csvPath entries
      charsetTable: non_cont      # Manticore charset_table preset; omit for the engine default
      memLimit: 2G                # Indexer memory limit during import
      hasHeader: true             # true if the CSV has a header row
      secondaryIndexes: false     # Build secondary indexes on attributes
    schema:
      columns:                    # See the column types table below
        - name: address_id
          type: attr_uint
        - name: street_number
          type: attr_uint
        - name: street_name
          type: field
        - name: city
          type: field
        - name: county
          type: field
        - name: state
          type: field
        - name: postal_code
          type: field
        - name: country
          type: field
        - name: latitude
          type: attr_float
        - name: longitude
          type: attr_float

If the first CSV column is numeric it becomes the document ID and must not be declared in schema.columns; otherwise an ID is generated.

Column type	Description
`field`	Full-text searchable field
`field_string`	Full-text field (string variant)
`attr_uint`	Unsigned integer attribute
`attr_bigint`	Big integer attribute
`attr_float`	Float attribute
`attr_bool`	Boolean attribute
`attr_string`	String attribute (not full-text indexed)
`attr_timestamp`	Timestamp attribute
`attr_multi`	Multi-value integer attribute
`attr_multi_64`	Multi-value 64-bit integer attribute
`attr_json`	JSON attribute

Multi-segment tables. To split a large dataset across several CSV files and query them as one distributed table, set csvPath to a list and segmentCount to its length. The chart refuses to render if they disagree. A backup of a multi-segment table covers all segments as one archive, and a restore replaces all of them.

tables:
  - name: addresses
    csvPath:
      - large-file/part1.csv
      - large-file/part2.csv
    config:
      segmentCount: 2
      memLimit: 2G
      hasHeader: true
    schema:
      columns:
        - name: street_name
          type: field

Multi-segment imports and clusterMain: true have not been verified at the shipped resource sizes. Treat them as untested rather than known-good, and validate per-replica row counts after an import if you rely on either.

Manticore

manticore:
  image: manticoresearch/manticore:25.0.0
  clusterName: manticore          # Galera cluster name
  resources:
    cpu: 4
    memory: 8Gi
  volumeset:
    capacity: 200                 # GB per replica
  sharedVolumeset:
    capacity: 100                 # GB shared across replicas and orchestrator
  autoscaling:
    minScale: 3                   # Replica count the orchestrator coordinates across
    maxScale: 4
    metric: rps                   # rps for stateful, cpu for standard
    target: 100
    scaleToZeroDelay: 300
  rolloutOptions:
    maxSurgeReplicas: 25%
    minReadySeconds: 10
    scalingPolicy: OrderedReady
    terminationGracePeriodSeconds: 60
  firewall:
    internalAccess:
      type: same-gvc              # Required for Galera replication — do not narrow
      workloads: []

Orchestrator

The orchestrator block configures the cron job, the REST API, the agent sidecar, the web UI and the optional backup job.

orchestrator:
  version: v6.0.5
  image: ghcr.io/controlplane-com/manticore-orchestrator/manticore-cpln-api
  logLevel: debug                 # debug, info, warn, error
  resources:
    cpu: 1
    memory: 2Gi
  schedule: "0 * * * *"           # Cron schedule (default = every hour)
  action: import                  # init, import, health, repair
  tableName: addresses            # Must match a name in tables[]
  suspend: true                   # Start suspended (trigger via UI/API)
  timeoutSeconds: 900             # Container timeout (seconds, default 15 minutes)
  importMemLimit: 2G              # Memory limit for import jobs
  activeDeadlineSeconds: 14400    # Max job runtime (seconds, default 4 hours)

  api:
    version: v6.0.5
    image: ghcr.io/controlplane-com/manticore-orchestrator/manticore-cpln-api
    logLevel: debug
    importPollInterval: 30s
    importPollTimeout: 2h
    resources:
      cpu: 0.25
      memory: 256Mi
    autoscaling:
      maxScale: 3
      minScale: 2
      metric: cpu
      target: 80

  agent:
    version: v6.0.5
    image: ghcr.io/controlplane-com/manticore-orchestrator/manticore-cpln-agent
    tokenSecretName: my-manticore-agent-token   # REQUIRED prerequisite opaque secret — must exist BEFORE install
    resources:
      maxCpu: 250m
      minCpu: 100m
      maxMemory: 512Mi
      minMemory: 128Mi
    import:
      batchSize: 20000            # Rows per INSERT statement
    recovery:
      maxRetries: 5               # Retry attempts for cluster recovery
      initialBackoffSec: 5        # Initial delay between retries
      maxBackoffSec: 60           # Max backoff delay (exponential)

  ui:
    version: v6.0.5
    image: ghcr.io/controlplane-com/manticore-orchestrator/manticore-cpln-ui
    resources:
      cpu: 0.25
      memory: 0.25Gi
    publicAccess:
      enabled: false              # DANGER: the UI has no login of its own — see the warning below
    internalAccess:
      type: same-gvc              # same-gvc, same-org, workload-list, none
      workloads: []               # //gvc/{gvc}/workload/{name} links, used when type is workload-list
    autoscaling:
      maxScale: 2
      minScale: 1
      metric: cpu
      target: 80

  backup:
    enabled: false
    version: v6.0.5
    image: ghcr.io/controlplane-com/manticore-orchestrator/manticore-cpln-backup
    cloudAccountName: my-manticore-backup-cloudaccount
    s3Bucket: my-manticore-backup-bucket    # S3 bucket for backups
    s3Policy:                               # IAM policies for S3 access
      - my-manticore-backup-policy          # Custom policy created in S3 setup instructions
    s3Region: us-east-1
    dataSet: addresses            # Data set to back up
    prefix: manticore-backups     # S3 prefix/folder for backups
    schedules: [
      {"table":"addresses","type":"delta","schedule":"0 2 * * *"},     # Daily at 2am UTC
      {"table":"addresses","type":"main","schedule":"0 2 1 * *"}       # Monthly full backup on 1st at 2am UTC
      ]
    activeDeadlineSeconds: 14400  # Max job runtime (seconds, default 4 hours)
    resources:
      cpu: 1
      memory: 1Gi

The management UI has no authentication of its own. It holds the bearer token server-side and attaches it to every request it makes on a visitor’s behalf, so anyone who can reach the UI holds full cluster admin — imports, restores and repairs included. The token protects the orchestrator API, not the UI. Keep orchestrator.ui.publicAccess.enabled: false and reach the UI from inside the GVC, or place your own authenticating proxy in front of it before exposing it by any route, including a custom domain.

Domain

domain:
  enabled: false
  name: ""                        # FQDN, e.g., manticore.example.com
  dnsMode: cname                  # cname (subdomains) or ns (zone delegation)

When enabled, the domain routes /api/* to the orchestrator API (bearer token required) and everything else to the UI (no authentication — see the warning above).

Load Test

loadTest:
  enabled: false
  image: grafana/k6:0.47.0
  resources:
    cpu: 0.5
    memory: 512Mi
  vus: 10                         # Virtual users
  duration: "5m"                  # Test duration (e.g., 30s, 5m, 1h)
  rps: null                       # Target RPS (null = unlimited)
  replicas: 1                     # Number of k6 pods to spawn
  controller:
    image: alpine/curl            # Alpine image with curl pre-installed
    schedule: ""                  # Cron expression (empty = manual only)
    testDurationBuffer: 60        # Seconds added to duration before scale-down
  target:
    port: 9308                    # Manticore HTTP API port
    endpoint: search              # "search" or "sql"
  query:                          # Full JSON body for the /search endpoint
    index: addresses
    query:
      match:
        "*": "test"
    limit: 10
  thresholds:
    p95ResponseTime: 500          # ms
    errorRate: 0.01               # 1%

How to run a test and read its results is described under Load Testing.

Connecting

Target	Address	Notes
Manticore SQL	`RELEASE_NAME-manticore.GVC_NAME.cpln.local:9306`	MySQL protocol, no authentication — reachable only from inside the GVC
Manticore HTTP	`RELEASE_NAME-manticore.GVC_NAME.cpln.local:9308`	JSON search API, no authentication — reachable only from inside the GVC
Orchestrator API	`RELEASE_NAME-orchestrator-api.GVC_NAME.cpln.local:8080`	Requires `Authorization: Bearer TOKEN`; GVC-internal only
Web UI	`RELEASE_NAME-ui.GVC_NAME.cpln.local:3000`	Internal-only by default. With `orchestrator.ui.publicAccess.enabled: true` it also gets a `*.cpln.app` endpoint, shown under `status.canonicalEndpoint` in `cpln workload get RELEASE_NAME-ui --gvc GVC_NAME -o yaml`
Custom domain	`https://DOMAIN_NAME`	`/api/*` to the orchestrator API, everything else to the UI; only with `domain.enabled: true`

The bearer token is the value you stored in the secret named by orchestrator.agent.tokenSecretName:

cpln secret reveal SECRET_NAME -o yaml

Verify the cluster from inside a Manticore replica. The manticore container ships the mysql client, and searchd listens on loopback, so this works from any replica (substitute your manticore.clusterName for manticore in the status key if you changed it):

cpln workload exec RELEASE_NAME-manticore --gvc GVC_NAME --container manticore -- \
  mysql --protocol=tcp -h 127.0.0.1 -P 9306 -e "SHOW STATUS LIKE 'cluster_manticore_status'"

A healthy cluster reports primary. To use a MySQL client on your own machine instead, forward the SQL port and connect to 127.0.0.1:9306:

cpln port-forward RELEASE_NAME-manticore 9306:9306 --gvc GVC_NAME

First Run

An install indexes nothing: the tables you defined exist but are empty until the cluster has been initialized once and an import has run. Both are orchestrator actions. Run them from the UI (reachable from inside the GVC on port 3000), or from the CLI by pointing the cron job at the action and starting it — see Running Cluster Actions. Run init once, then import; repeat import whenever the CSVs in your source bucket change.

Operations

Running Cluster Actions

The RELEASE_NAME-orchestrator-job cron workload ships suspended. orchestrator.action selects what a run does — init bootstraps the Galera cluster, import loads the CSVs for orchestrator.tableName into a fresh slot and swaps it in without interrupting searches, health reports cluster state, and repair recovers from a split brain. Trigger a run on demand:

cpln workload cron start RELEASE_NAME-orchestrator-job --gvc GVC_NAME

The UI exposes the same actions plus backup and restore. Follow a run in the job’s logs:

cpln logs '{gvc="GVC_NAME", workload="RELEASE_NAME-orchestrator-job"}' --limit 50 --since 10m

To run on a schedule instead, set orchestrator.suspend: false; orchestrator.schedule then applies.

Backing Up

Backups are logical delta (incremental) and main (full) archives written to a separate S3 bucket by the RELEASE_NAME-manticore-backup cron workload, under its own identity. Do not widen the source-bucket policy; give backups their own bucket and policy.

Create the backup bucket and a writable policy

Create a second bucket and an IAM policy with the following JSON, replacing my-manticore-backup-bucket. GetObject and DeleteObject let restores read an archive back and lifecycle cleanup remove one; a backup-only install can drop them.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket", "s3:GetBucketLocation"],
      "Resource": "arn:aws:s3:::my-manticore-backup-bucket"
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::my-manticore-backup-bucket/*"
    }
  ]
}

Attach it to a cloud account and enable backups

Attach the policy to the role your cloud account uses, then set orchestrator.backup.enabled: true together with orchestrator.backup.cloudAccountName, s3Bucket, s3Region and s3Policy.

orchestrator.backup.schedules drives the automated runs (daily delta and monthly main by default). You can also run a backup on demand from the UI, or from any workload inside the GVC against the orchestrator API:

curl -X POST "http://RELEASE_NAME-orchestrator-api.GVC_NAME.cpln.local:8080/api/backup" \
  -H "Authorization: Bearer TOKEN" -H "Content-Type: application/json" \
  -d '{"tableName": "addresses", "type": "delta"}'

After enabling backups, confirm that objects appear in the bucket after the first scheduled run.

Restoring a Backup

Restore is driven through the UI or the orchestrator API; there is no orchestrator.action: restore. List the available archives (type defaults to delta, so pass type=main to see full backups), then restore one by filename:

curl "http://RELEASE_NAME-orchestrator-api.GVC_NAME.cpln.local:8080/api/backups/files?tableName=addresses&type=main" \
  -H "Authorization: Bearer TOKEN"

curl -X POST "http://RELEASE_NAME-orchestrator-api.GVC_NAME.cpln.local:8080/api/restore" \
  -H "Authorization: Bearer TOKEN" -H "Content-Type: application/json" \
  -d '{"tableName": "addresses", "type": "main", "filename": "ARCHIVE_FILENAME.tar.gz"}'

A restore scales the cluster up by one replica while it runs and puts it back afterwards. After restoring a main backup, use the UI’s Rotate Main control to swap the active slot.

A restore can land on some replicas and not others while every node still reports synced, so cluster status alone does not confirm it. Count rows on each replica (the stateful replicas are named RELEASE_NAME-manticore-0, -1, -2, …):

cpln workload exec RELEASE_NAME-manticore --gvc GVC_NAME --replica RELEASE_NAME-manticore-0 --container manticore -- \
  mysql --protocol=tcp -h 127.0.0.1 -P 9306 -e "SELECT COUNT(*) FROM addresses"

If the counts disagree, run a fresh import of the table from your source CSVs, which rebuilds every replica.

Upgrading from 2.0.1 or Earlier

2.0.1 and earlier shipped a live working bearer token as a values default, published in the template repository, so every install that did not override it shared one publicly-known credential. The management UI was also public by default while having no login of its own, and the chart’s secret policy granted reveal on every secret in the organization rather than the four it needed. Treat the token on any earlier install as compromised: rotate it rather than simply upgrading.

2.0.1 and earlier	2.1.0 and later
`orchestrator.agent.token` (a working value)	`orchestrator.agent.tokenSecretName` names a prerequisite opaque secret
`orchestrator.ui.allowExternalAccess: true`	`orchestrator.ui.publicAccess.enabled: false`
UI internal scope hardcoded	`orchestrator.ui.internalAccess.type` (`same-gvc`)
Policy granted `reveal` org-wide	Scoped to exactly four secrets
Scheduled backup failed on every run	Backup works; restore via UI or API
Source-bucket IAM asked for write	Read-only is sufficient

Both removed keys stop the render with a message naming their replacement, so an upgrade cannot silently fall back to a default:

orchestrator.agent.token was REMOVED in manticore 2.1.0. The bearer token is now a
prerequisite opaque secret you create before install; set
orchestrator.agent.tokenSecretName to its name instead.

Create the agent-token secret

Generate a fresh token — do not carry the old one forward — and create the secret as shown in Prerequisites.

Replace the removed keys

Delete orchestrator.agent.token and orchestrator.ui.allowExternalAccess from your values, then set orchestrator.agent.tokenSecretName. If you were relying on external UI access, decide deliberately whether to set orchestrator.ui.publicAccess.enabled: true — it publishes cluster admin.

Narrow the source-bucket policy

If you granted s3:PutObject or s3:DeleteObject on your source data bucket, reduce it to the read-only policy shown in Prerequisites.

Verify backups if you use them

Scheduled backups did not work on any earlier version, so an install with backups enabled had none. After upgrading, confirm that objects appear in the backup bucket after the first scheduled run.

Upgrading from 2.1.0

The agent sidecar’s resource block exposes both a reservation and a limit, so 2.2.0 names the limit maxCpu / maxMemory instead of cpu / memory. Rename the two keys under orchestrator.agent.resources in your values:

2.1.0	2.2.0
`orchestrator.agent.resources.cpu`	`orchestrator.agent.resources.maxCpu`
`orchestrator.agent.resources.memory`	`orchestrator.agent.resources.maxMemory`

minCpu and minMemory are unchanged, and blocks that expose only a limit (manticore.resources, orchestrator.resources, orchestrator.api.resources, orchestrator.ui.resources, orchestrator.backup.resources, loadTest.resources) keep the bare cpu / memory names. An upgrade that still carries the old names is refused at render:

manticore: orchestrator.agent.resources.cpu was RENAMED to orchestrator.agent.resources.maxCpu.

Scaling and Availability

manticore.autoscaling.minScale is both the minimum replica count and the replica count the orchestrator coordinates imports across. Changing it after the cluster is initialized requires a repair run.
Every helm upgrade — including one that changes nothing — restarts the Manticore replicas one at a time (scalingPolicy: OrderedReady). Indexed data survives, and searches keep serving from the replicas that are still up, but budget for the full serial rollout. Editing tables changes a mounted secret and therefore triggers the same rollout.
manticore.firewall.internalAccess.type must stay same-gvc: Galera replication between replicas depends on it, and Manticore’s SQL and HTTP ports have no authentication of their own, so they rely on that firewall. Allow a few minutes for any access change to take effect.

Load Testing

With loadTest.enabled: true, trigger a run by starting the controller; it scales the k6 workload up to loadTest.replicas, waits duration plus testDurationBuffer, then scales it back to zero:

cpln workload cron start RELEASE_NAME-load-test-controller --gvc GVC_NAME

Read the results — including whether each threshold passed — from the runner’s logs:

cpln logs '{gvc="GVC_NAME", workload="RELEASE_NAME-load-test"}' --limit 50 --since 10m

The last lines are k6’s end-of-test summary (http_req_duration, http_req_failed, a pass/fail mark per threshold) followed by k6 exited with status N — non-zero means a threshold was breached. Set loadTest.controller.schedule to a cron expression to run tests automatically.

Troubleshooting

Deployment never becomes ready after install and cpln logs returns nothing

Cause: the agent-token secret named by orchestrator.agent.tokenSecretName did not exist at install time. The containers never start, so there is no log output; the only place the missing secret is named is status.versions[].message.Fix: read the message, create the secret, and the deployment recovers on its own (or force a redeployment to skip the wait):

cpln workload get-deployments RELEASE_NAME-manticore --gvc GVC_NAME -o yaml
cpln workload force-redeployment RELEASE_NAME-manticore --gvc GVC_NAME

orchestrator.agent.token was REMOVED in manticore 2.1.0

Cause: your values still carry a key from 2.0.1 or earlier. The same guard reports orchestrator.ui.allowExternalAccess was REMOVED in manticore 2.1.0.Fix: follow Upgrading from 2.0.1 or Earlier.

orchestrator.agent.resources.cpu was RENAMED to orchestrator.agent.resources.maxCpu

Cause: your values still use the 2.1.0 names for the agent sidecar’s limits. The same guard reports orchestrator.agent.resources.memory was RENAMED to orchestrator.agent.resources.maxMemory.Fix: rename the two keys as shown in Upgrading from 2.1.0.

csvPath has N entries but segmentCount is M — they must match

Cause: a table’s config.segmentCount does not equal the number of csvPath entries (or csvPath is a single string while segmentCount is not 1).Fix: set segmentCount to the number of CSV paths for that table.

Searches return no results

Cause: an install alone indexes nothing. The tables exist but are empty until the cluster has been initialized and an import has run.Fix: run init once and then import as described in Running Cluster Actions, then confirm with SELECT COUNT(*) on the table.

Row counts differ between replicas after a restore

Cause: a restore can land on some replicas and not others while every node still reports synced.Fix: count rows on each replica as shown in Restoring a Backup; if they disagree, run a fresh import of the table, which rebuilds every replica from the source CSVs.

Important Notes

Create the agent-token secret before installing; without it the deployment wedges silently and status.versions[].message is the only diagnostic.
Enabling orchestrator.ui.publicAccess or routing a domain to the UI puts an unauthenticated admin console on the public internet. Only do it behind your own authenticating proxy.
Keep manticore.firewall.internalAccess.type at same-gvc; Galera replication requires it and Manticore’s 9306/9308 ports have no authentication.
Tables are empty until you run init followed by import; the install alone does not load data.
The source bucket only ever needs read access. Only the optional backup bucket needs write, and it has its own identity and policy.
Every helm upgrade restarts all Manticore replicas one at a time; data survives, but plan the rollout window.
Verify per-replica row counts after a restore rather than trusting cluster status.
Uninstalling deletes both volume sets and all indexed data. Take a backup first if you need it.

External References