Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 9 additions & 7 deletions deployments/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -38,9 +38,13 @@ cd scripts
./deploy-osmo-minimal.sh --provider aws
```

For a development evaluation, use the unified chart's `quickstart.yaml`
profile. Kind is the recommended local cluster; KAI Scheduler, CloudNativePG,
and a default dynamic StorageClass must already be available:
For a development evaluation, use the unified chart defaults. Kind is the
recommended local cluster; KAI Scheduler, CloudNativePG, and a default dynamic
StorageClass must already be available:

Before installing OSMO, generate the shared service-auth identity and create
the required `osmo-service-auth` Secret by following the
[`osmo` chart installation steps](charts/osmo/README.md#install-osmo).

```bash
helm repo add cnpg https://cloudnative-pg.github.io/charts
Expand All @@ -56,8 +60,6 @@ helm dependency build deployments/charts/osmo
helm --kube-context kind-osmo upgrade --install osmo deployments/charts/osmo \
--namespace osmo \
--create-namespace \
--values deployments/charts/osmo/profiles/quickstart.yaml \
--set-string compute.backendName=default \
--wait \
--wait-for-jobs \
--timeout 20m
Expand All @@ -75,8 +77,8 @@ helm --kube-context kind-osmo upgrade osmo deployments/charts/osmo \
--timeout 20m
```

The quick-start profile installs the control and compute planes, PostgreSQL,
Valkey, and RustFS in one development OSMO release and creates its credentials
The quickstart defaults install the control and compute planes, PostgreSQL,
Valkey, and RustFS in one development OSMO release and create its credentials
and buckets automatically. See
[`charts/osmo/README.md`](charts/osmo/README.md) for readiness checks,
port-forwarding, hello-world validation, recovery, and split-plane deployment.
Expand Down
21 changes: 12 additions & 9 deletions deployments/charts/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -28,15 +28,17 @@ the unified chart.

For an existing development cluster with KAI Scheduler, the CloudNativePG
operator, and a default dynamic StorageClass, install the complete browser,
CLI, API, and CPU workflow experience with one unified OSMO release:
CLI, API, and CPU workflow experience with the chart defaults:

Before running Helm, generate the shared service-auth identity and create the
required `osmo-service-auth` Secret by following the
[`osmo` installation steps](osmo/README.md#install-osmo).

```bash
helm dependency build deployments/charts/osmo
helm --kube-context kind-osmo upgrade --install osmo deployments/charts/osmo \
--namespace osmo \
--create-namespace \
--values deployments/charts/osmo/profiles/quickstart.yaml \
--set-string compute.backendName=default \
--wait \
--wait-for-jobs \
--timeout 20m
Expand All @@ -54,15 +56,16 @@ helm --kube-context kind-osmo upgrade osmo deployments/charts/osmo \
--timeout 20m
```

The profile deploys the UI, gateway, control and compute planes, a CloudNativePG
Cluster, persistent Valkey, and persistent RustFS. It generates development
credentials, creates the workflow/log/app buckets, and connects the backend
without a manual Secret copy. The UI and API are exposed through gateway
NodePort `30080`.
The default values deploy the UI, gateway, control and compute planes, a
CloudNativePG Cluster, persistent Valkey, and persistent RustFS. They generate
development credentials, create the workflow/log/app buckets, and connect the
backend without a manual Secret copy. The UI and API are exposed through
gateway NodePort `30080`.

See the [`osmo` quick-start guide](osmo/README.md#quick-start) for prerequisite
installation, browser and CLI access, a hello-world workflow, capacity,
troubleshooting, cleanup, and the profile's non-production limitations.
troubleshooting, cleanup, and the default quickstart's non-production
limitations.

## Self-contained production

Expand Down
55 changes: 29 additions & 26 deletions deployments/charts/osmo/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,8 +7,8 @@ SPDX-License-Identifier: Apache-2.0

The `osmo` chart is the unified OSMO deployment entry point.

See the [profile matrix](profiles/README.md) for which values files are directly
installable profiles and which are base overlays requiring environment input.
The chart defaults are the development quickstart. See the
[profile matrix](profiles/README.md) for production and split-plane overlays.

The chart supports control-only, compute-only, and converged releases. It can
render backend listener and worker resources directly with the control services,
Expand All @@ -21,9 +21,9 @@ installations, but it is not a dependency of this chart.

## Quick start

The `quickstart.yaml` profile is a development-only path to trying the complete
OSMO browser, CLI, API, and CPU workflow experience in one converged release.
It installs:
The default values are a development-only path to trying the complete OSMO
browser, CLI, API, and CPU workflow experience in one converged release. They
install:

- the Envoy gateway and browser UI;
- the API, worker, router, logger, agent, and delayed-job monitor;
Expand Down Expand Up @@ -64,7 +64,7 @@ helm --kube-context kind-osmo upgrade --install cnpg cnpg/cloudnative-pg \
### Install OSMO

Generate the shared development service-auth identity, create its Secret, then
install the unified chart with the single quick-start values file:
install the unified chart without a values file or required `--set` values:

```bash
OSMO_SERVICE_AUTH_DIRECTORY="$(mktemp -d)"
Expand All @@ -83,8 +83,6 @@ helm dependency build deployments/charts/osmo
helm --kube-context kind-osmo upgrade --install osmo deployments/charts/osmo \
--namespace osmo \
--create-namespace \
--values deployments/charts/osmo/profiles/quickstart.yaml \
--set-string compute.backendName=default \
--wait \
--wait-for-jobs \
--timeout 20m
Expand Down Expand Up @@ -186,13 +184,14 @@ kubectl --context kind-osmo delete namespace osmo \

### Capacity and limitations

The profile runs one replica of every required OSMO service, including the UI
and delayed-job monitor, and uses persistent volumes for PostgreSQL (1 GiB),
Valkey (512 MiB), and RustFS (1 GiB). PostgreSQL requests 1 CPU and 2 GiB, while
Valkey and RustFS each request 500 millicores and 1 GiB. The nine OSMO services
request 100 millicores and 256 MiB each, and the gateway requests 50 millicores
and 64 MiB. Those long-running pods reserve approximately 2.95 CPU and 6.4 GiB
before Kubernetes, KAI, and CloudNativePG operator overhead.
The default quickstart runs one replica of every required OSMO service,
including the UI and delayed-job monitor, and uses persistent volumes for
PostgreSQL (1 GiB), Valkey (512 MiB), and RustFS (1 GiB).
PostgreSQL requests 1 CPU and 2 GiB, while Valkey and RustFS each request 500
millicores and 1 GiB. The nine OSMO services request 100 millicores and 256 MiB
each, and the gateway requests 50 millicores and 64 MiB. Those long-running pods
reserve approximately 2.95 CPU and 6.4 GiB before Kubernetes, KAI, and
CloudNativePG operator overhead.

The canonical hello-world pod additionally requests 1 CPU, 1 GiB of memory, and
1 GiB of ephemeral storage for both its user container and its `osmo-ctrl`
Expand Down Expand Up @@ -387,7 +386,8 @@ helm upgrade --install osmo deployments/charts/osmo \
--timeout 25m
```

The defaults create three PostgreSQL 16 instances with one 20 Gi
The split-plane control profile uses production-oriented settings that create
three PostgreSQL 16 instances with one 20 Gi
Comment thread
ecolternv marked this conversation as resolved.
`ReadWriteOnce` PVC per instance, required hostname anti-affinity, a
PodDisruptionBudget, and synchronous replication to one standby. A generated
application Secret is wired into every OSMO PostgreSQL client automatically.
Expand Down Expand Up @@ -451,7 +451,8 @@ secrets:
key: mek.yaml
```

Keep `embeddedDependencies.postgresql.enabled: false` (the default), then
Keep `embeddedDependencies.postgresql.enabled: false` as set by the
split-plane control profile, then
install the chart by layering the environment values after the profile:

```bash
Expand Down Expand Up @@ -509,8 +510,8 @@ used by clients and control-plane configuration.

## Embedded Valkey

Embedded Valkey is disabled by default. Enable it with retained generated
credentials as follows:
The quickstart defaults enable a small embedded Valkey. A profile that disables
it can enable it with retained generated credentials as follows:

```yaml
embeddedDependencies:
Expand All @@ -527,7 +528,9 @@ secrets:
existingSecret: ''
```

The generated Secret and 8 GiB `ReadWriteOnce` PVC are retained on uninstall.
The generated Secret and configured `ReadWriteOnce` PVC are retained on
uninstall. The quickstart uses 512 MiB; the split-plane control profile uses
8 GiB when embedded Valkey is enabled there.
Back up both resources and restore the original Secret before reinstalling or
recovering the PVC. To supply an existing Secret instead, disable
`secrets.valkey.generate` and set both `secrets.valkey.existingSecret` and
Expand Down Expand Up @@ -579,12 +582,12 @@ rustfs:
existingSecret: osmo-rustfs-credentials
```

The chart deploys a standalone RustFS instance with a retained 10 GiB
`ReadWriteOnce` PVC. A regular Job waits for RustFS and creates the configured
workflow, log, and app buckets when they are absent. Use `--wait-for-jobs` with
Helm so an install or upgrade does not return before bucket bootstrap succeeds.
OSMO is configured with the RustFS endpoint, buckets, and generated credentials
automatically.
The split-plane control profile deploys a standalone RustFS instance with a
retained 10 GiB `ReadWriteOnce` PVC when embedded object storage is enabled.
A regular Job waits for RustFS and creates the configured workflow, log, and
app buckets when they are absent. Use `--wait-for-jobs` with Helm so an install
or upgrade does not return before bucket bootstrap succeeds. OSMO is configured
with the RustFS endpoint, buckets, and generated credentials automatically.

The generated `osmo-rustfs-credentials` Secret is retained on uninstall and
reused on upgrades. To provide an existing Secret, disable
Expand Down
20 changes: 10 additions & 10 deletions deployments/charts/osmo/profiles/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,27 +5,27 @@ SPDX-License-Identifier: Apache-2.0

# OSMO chart profiles

Profiles are values-file overlays, not a `profile` value selected by the chart.
Layer environment-specific values after a base overlay so that the environment
values take precedence.
The chart defaults provide the development quickstart. Profiles are values-file
overlays, not a `profile` value selected by the chart. Layer environment-specific
values after a base overlay so that the environment values take precedence.

| File | Directly installable | Required environment input |
| --- | --- | --- |
| `quickstart.yaml` | Yes, on a development cluster | KAI Scheduler, the CloudNativePG operator, and a default dynamic StorageClass installed separately; `osmo-service-auth` generated and created as documented; `compute.backendName` set explicitly at install time |
| `self-contained.yaml` | Yes, with production inputs | KAI Scheduler, the CloudNativePG operator, a default dynamic StorageClass, at least four schedulable nodes, a NetworkPolicy-enforcing CNI, an OIDC client and Secret with role assignments, an `osmo-service-auth` Secret generated as documented, a TLS edge and public `externalUrl`, IPv4 cluster CIDRs, and `compute.backendName` |
| Chart defaults (`values.yaml`) | Yes, on a development cluster | KAI Scheduler, the CloudNativePG operator, and a default dynamic StorageClass installed separately; `osmo-service-auth` generated and created as documented |
| `self-contained.yaml` | Yes, with production inputs | KAI Scheduler, the CloudNativePG operator, a default dynamic StorageClass, at least four schedulable nodes, a NetworkPolicy-enforcing CNI, an OIDC client and Secret with role assignments, an `osmo-service-auth` Secret generated as documented, a TLS edge and public `externalUrl`, and IPv4 cluster CIDRs |
| `split-plane-control.yaml` | Base overlay | PostgreSQL, Valkey, and object-storage endpoints; Kubernetes Secrets; and `externalUrl` |
| `split-plane-compute.yaml` | Base overlay | A control-plane `externalUrl`, a compute authentication Secret, and `compute.backendName` set explicitly at install time |

The quick-start profile is the smallest complete control-and-compute deployment
The default values are the smallest complete control-and-compute deployment
for browser, CLI, and CPU hello-world verification. It exposes the UI and API
through gateway NodePort `30080` while omitting optional production behavior.
It intentionally uses `latest` OSMO images, one replica per component,
development authentication, explicitly generated service auth, and small
single-node stateful dependencies.
The quick-start installation path uses the chart's default image settings and
does not require application Secrets or an image-pull Secret to be created
beforehand. Configure top-level `imagePullSecrets` only when using a registry
that requires credentials.
The quick-start installation path requires the documented pre-created
`osmo-service-auth` Secret. It generates its other application credentials and
does not require an image-pull Secret beforehand. Configure top-level
`imagePullSecrets` only when using a registry that requires credentials.

The self-contained profile is the production-converged path for environments
that host OSMO and its stateful dependencies in Kubernetes. It uses chart-version
Expand Down
Loading
Loading