percona/pxc-operator

Three ways this page helps you test

The same three things hold for every package in the catalog, Helm charts and OCI packages alike. Why this makes configuration easier to test.

What To Use

default base variant: 7 rendered objects · 3 images · 0 lifecycle routes · 6/6 proof lanes passing. Every number is extracted from committed data.

The recipe/package proof exists and useful variants exist, but this chart has not been promoted into the public catalog.

Where This Chart's Settings Come From

Helm values define each base render. ConfigHub changes begin after upload and are recorded against the rendered objects. Secrets, CRDs, hooks, and setup jobs are listed separately because they are install work, not hidden settings. Live cluster state is observed separately and does not silently become the desired configuration.

Upgrade rule: if a new Helm render and a ConfigHub revision both change the same field, review the overlap before promotion. The values profile shows the Helm side; Unit revision history shows the ConfigHub side.

Read the full values-versus-ConfigHub rule.

What A Base Variant Records

A base variant solves the first Helm problem: which chart inputs should we use, and what Kubernetes objects do they produce? Each base variant records the Helm chart version, values profile, namespace, release name, capability profile, source lock, generated output, and evidence lanes.

The default base-variant record joins those Helm facts to the literal objects, remaining target inputs, hooks and CRDs, apply policy, and OCI handoffs. It is the short record to open when you need the whole base rather than only its rendered YAML.

Open the full rendered YAML to read the actual manifest output. Then use the render intent, receipts, and chart-extras section to see the inputs, checks, and CRD/hook/setup decisions around it.

If your values file creates a new useful operating shape, it should become another base variant with its own recorded inputs and checks. If it only changes an already-rendered field after upload, it belongs in a derived ConfigHub variant that can be reviewed and kept through upgrades.

How render intents work · All generated render intents · All base variant records

How To Try This Chart

Start with default unless a card below explains that another base variant is a better first path. If a card says review or preparation is needed, treat that as a real limit rather than a ready install.

cub installer setup ...
rendered manifests written under <work-dir>
use the chart option cards below to check pass, watch, blocked, and prerequisites

Base Variants And Options

Each card is one available way to use this chart in the catalog. Some cards are runnable base variants. Others are candidate paths, derived variants, or review notes that explain what still has to be prepared.

Check labels: R = render parity, C = ConfigHub proof, L = local cluster, Y = lifecycle actions, G = GitOps/OCI, P = live Helm-vs-ConfigHub parity, K = two-cluster kind parity, V = variant promotion.

3 matrix rows for percona/pxc-operator@1.19.1 · open the full matrix

Images This Chart Pulls

Every reference below comes from the reviewed rendered output. What you see is what the cluster pulls. These references are data: you can change a registry or pin a digest with a recorded edit, and prove the change landed in every environment.

First-Run Caveats

Some chart paths need a small preparation step before the cub path feels as smooth as Helm. We show those steps here so the first run does not surprise you.

Open the all-chart adoption caveats · Helm to cub migration · cub deployment path

Operator Playbooks And Fact Sheet

This is the quick route for a human or agent: which operating playbook applies, what the current user-facing answer is, and what the next proof or product action would add.

The source data lives in chart skills and chart evidence router.

Proof Lanes

Each lane proves a different outcome. Missing or non-pass rows are backlog or target-fit evidence; they do not change the render-parity result.

How much is proven, and what more testing would add: Fully proven: Render parity, ConfigHub proof, GitOps/OCI live, Live Helm-vs-ConfigHub, Two-cluster kind. Proven on some bases: Local live.

Quirks And Inputs

exact rendered objects with render parity and receipts; CRD handling split into explicit bases; extension slots routed to reviewed bases; install-vs-upgrade render divergence captured per revision; cluster lookups lifted into declared target facts

Hooks, CRDs, And Setup Work

Some Helm charts need work before, during, or after apply: CRDs, hooks, setup jobs, webhook certificates, migrations, generated Secrets, or checks. For each chart, the catalog should make the choice clear: include it in the base variant, split it into a separate base variant, run a setup step, use a GitOps action where evidence exists, require an existing target resource, or block it when there is no safe default.

What each base needs before apply

These requirements come from the same base definition as the rendered objects. The render intent keeps the chart inputs, required Secrets or CRDs, lifecycle routes, and evidence together.

If no route is shown, that does not prove the upstream chart has no hooks. It means the public catalog has no chart-specific action to show yet; check the matrix or send a problem chart if hook behavior should be modeled. Direct apply, Argo CD, Flux, and upgrade implementations are tracked separately. One passing implementation does not prove the others.

No chart-specific action is attached to this page yet. That is not a claim that the upstream chart has no hooks or setup work. It means the public catalog has no per-chart-base variant action to show here; check the Helm Ops Catalog filters, the matrix, or send a problem chart if hook behavior should be modeled.

Production Boundary

A green render or local live result is not a production support claim. Production support is target-scoped and uses the support-decision artifact when present.

Files To Inspect