Umbrella chart add single plane deploy script

.github/workflows/helm-chart-lint.yaml

@@ -69,12 +69,12 @@ jobs:
 
           if [ -z "$CHARTS" ]; then
             echo "No chart changes detected"
-            echo "has_changes=false" >> $GITHUB_OUTPUT
-            echo "charts=[]" >> $GITHUB_OUTPUT
+            echo "has_changes=false" >> "$GITHUB_OUTPUT"
+            echo "charts=[]" >> "$GITHUB_OUTPUT"
           else
             echo "Changed charts: [$CHARTS]"
-            echo "has_changes=true" >> $GITHUB_OUTPUT
-            echo "charts=[$CHARTS]" >> $GITHUB_OUTPUT
+            echo "has_changes=true" >> "$GITHUB_OUTPUT"
+            echo "charts=[$CHARTS]" >> "$GITHUB_OUTPUT"
           fi
 
   #######################
@@ -130,6 +130,14 @@ jobs:
               --kube-version 1.30.0 \
               -f deployments/charts/osmo/profiles/split-plane-compute.yaml \
               --set-string compute.backendName=test-backend
+            helm lint deployments/charts/osmo \
+              --kube-version 1.30.0 \
+              -f deployments/charts/osmo/profiles/single-plane.yaml \
+              -f deployments/charts/osmo/tests/single-plane-azure-values.yaml
+            helm lint deployments/charts/osmo \
+              --kube-version 1.30.0 \
+              -f deployments/charts/osmo/profiles/single-plane.yaml \
+              -f deployments/charts/osmo/tests/single-plane-s3-values.yaml
             helm lint deployments/charts/osmo \
               --kube-version 1.30.0 \
               -f deployments/charts/osmo/profiles/kind-self-contained.yaml \
@@ -167,6 +175,16 @@ jobs:
               -f deployments/charts/osmo/profiles/split-plane-compute.yaml \
               --set-string compute.backendName=test-backend \
               >/dev/null
+            helm template test-single-plane-azure deployments/charts/osmo \
+              --kube-version 1.30.0 \
+              -f deployments/charts/osmo/profiles/single-plane.yaml \
+              -f deployments/charts/osmo/tests/single-plane-azure-values.yaml \
+              >/dev/null
+            helm template test-single-plane-s3 deployments/charts/osmo \
+              --kube-version 1.30.0 \
+              -f deployments/charts/osmo/profiles/single-plane.yaml \
+              -f deployments/charts/osmo/tests/single-plane-s3-values.yaml \
+              >/dev/null
             helm template test-kind deployments/charts/osmo \
               --kube-version 1.30.0 \
               --api-versions postgresql.cnpg.io/v1 \

deployments/BUILD

@@ -18,5 +18,9 @@ SPDX-License-Identifier: Apache-2.0
 
 exports_files([
     "scripts/common.sh",
+    "scripts/deploy-osmo-umbrella-single-plane.sh",
+    "scripts/single-plane-azure.yaml.envsubst",
     "scripts/deploy-k8s.sh",
+    "scripts/verify.sh",
+    "workflows/verify-hello.yaml",
 ])

deployments/charts/osmo/README.md

@@ -128,6 +128,8 @@ osmo workflow query <workflow-id> --format-type json
 ```
 
 Repeat the query until the workflow status is `COMPLETED`.
+The workflow passes a marker between its two tasks through the configured
+object store, so completion validates both upload and download access.
 
 ### Troubleshooting and cleanup
 
@@ -175,6 +177,80 @@ configuration. Use a production profile with managed credentials, TLS,
 authorization, backups, suitable resource sizing, and HA dependencies for
 long-lived environments.
 
+## Single-plane external dependencies
+
+`profiles/single-plane.yaml` is a provider-neutral, converged base overlay for
+one cluster that runs both the control and compute planes. It disables embedded
+PostgreSQL, Valkey, and object storage, while retaining the gateway as a
+`ClusterIP` Service. Layer a site-specific values file after it for the public
+URL, external dependency connections, and backend name. Ingress is deliberately
+an external, later step; enable and configure it only when the site has its
+ingress controller and public DNS ready.
+
+The profile configures Envoy to validate supplied OSMO access tokens against the
+API service's in-cluster `https://osmo-api/api/auth/keys` endpoint. Missing JWTs
+remain allowed so the development default identity and `--method=dev` login keep
+working; malformed or invalid supplied JWTs are rejected. External identity
+providers remain site-specific gateway configuration.
+
+Object storage uses exact `locations` for workflow data, logs, and apps. All
+three locations must use the same URI scheme. The URI scheme selects the storage
+backend: Azure locations use `azure://<account>/<container>/<prefix>`, while S3
+locations use `s3://<bucket>/<prefix>`. Azure locations forbid the S3-only
+settings in `externalDependencies.objectStorage.s3`; set that block only for S3
+locations. Authentication is independent of the URI scheme:
+
+- `authentication.type: static` is the default. Store credentials for all
+  three locations in one pre-provisioned Kubernetes Secret selected by
+  `secrets.objectStorage.existingSecret`.
+- `authentication.type: sdkDefault` omits static credential mounts and lets the
+  provider SDK discover credentials, such as Azure DefaultAzureCredential, the
+  AWS default credential provider chain, or Google Application Default
+  Credentials. Leave `secrets.objectStorage.existingSecret` empty.
+
+Do not place credential material in values files or Helm command lines.
+
+For example, an Azure site overlay contains only its connection values and
+locations:
+
+```yaml
+externalDependencies:
+  objectStorage:
+    authentication:
+      type: sdkDefault
+    locations:
+      workflows: azure://osmoazure/osmo-workflows/workflows
+      logs: azure://osmoazure/osmo-workflows/logs
+      apps: azure://osmoazure/osmo-workflows/apps
+```
+
+An S3 site uses the S3 URI scheme and its S3-specific settings instead:
+
+```yaml
+externalDependencies:
+  objectStorage:
+    authentication:
+      type: static
+    locations:
+      workflows: s3://osmo-workflows/workflows
+      logs: s3://osmo-logs/logs
+      apps: s3://osmo-apps/apps
+    s3:
+      region: us-east-1
+      overrideUrl: https://s3.example.com
+```
+
+Install the generic profile first and the site overlay second. The example
+Azure overlay is generated by
+[`deploy-osmo-umbrella-single-plane.sh`](../../scripts/deploy-osmo-umbrella-single-plane.sh):
+
+```bash
+helm upgrade --install osmo deployments/charts/osmo \
+  --namespace osmo \
+  --values deployments/charts/osmo/profiles/single-plane.yaml \
+  --values single-plane-azure.yaml
+```
+
 ## Full kind development profile
 
 The `kind-self-contained.yaml` profile is for development only. It expects an
@@ -243,6 +319,8 @@ osmo workflow query <workflow-id> --format-type json
 Repeat the query until the workflow status is `COMPLETED`. A `FAILED` or
 `CANCELLED` status is an acceptance failure; inspect `osmo workflow logs` and
 namespace events before retrying.
+The workflow passes a marker between its two tasks through the configured
+object store, so completion validates both upload and download access.
 
 The profile creates the three object-storage buckets and wires their RustFS
 endpoint and credential Secret into the control plane. It also creates a
@@ -336,12 +414,13 @@ externalDependencies:
     port: 6379
     database: 0
   objectStorage:
-    endpoint: https://s3.example.com
-    region: us-east-1
-    buckets:
-      workflows: osmo-workflows
-      logs: osmo-logs
-      apps: osmo-apps
+    locations:
+      workflows: s3://osmo-workflows/workflows
+      logs: s3://osmo-logs/logs
+      apps: s3://osmo-apps/apps
+    s3:
+      region: us-east-1
+      overrideUrl: https://s3.example.com
 
 secrets:
   postgresql:
@@ -466,11 +545,13 @@ embeddedDependencies:
 
 externalDependencies:
   objectStorage:
-    endpoint: ''
-    buckets:
+    locations:
       workflows: ''
       logs: ''
       apps: ''
+    s3:
+      region: ''
+      overrideUrl: ''
 
 secrets:
   objectStorage:
@@ -514,10 +595,13 @@ above.
   OSMO component tag under `imageTag`, pull credentials under
   `imagePullSecrets`, and workflow init/client images under `runtimeImage`.
   The chart writes those workflow images into the managed API configuration
-  unless `configuration.workflow.backend_images` overrides them. Configure
-  per-component image overrides in each component's `image` block. Configure
-  dependency images and pull credentials in their native values blocks; for
-  example, Valkey uses `valkey.image` and `valkey.imagePullSecrets`.
+  unless `configuration.workflow.backend_images` overrides them. Set
+  `runtimeImage.pullSecret` to a Docker config Secret when those workflow
+  images are private; OSMO converts it into workflow-scoped pull credentials.
+  Configure per-component image overrides in each component's `image` block.
+  Configure dependency images and pull credentials in their native values
+  blocks; for example, Valkey uses `valkey.image` and
+  `valkey.imagePullSecrets`.
 - Configure replicas, autoscaling, resources, disruption budgets, scheduling,
   security contexts, probes, volumes, and ServiceAccounts under `services`,
   `gateway`, and `podDefaults`. Directly owned workload extensions use

deployments/charts/osmo/embedded-rustfs-ha-values.yaml

@@ -14,11 +14,13 @@ embeddedDependencies:
 
 externalDependencies:
   objectStorage:
-    endpoint: ''
-    buckets:
+    locations:
       workflows: ''
       logs: ''
       apps: ''
+    s3:
+      region: ''
+      overrideUrl: ''
 
 secrets:
   objectStorage:

deployments/charts/osmo/profiles/README.md

@@ -13,6 +13,7 @@ values take precedence.
 | --- | --- | --- |
 | `quickstart.yaml` | Yes, on a development cluster | KAI Scheduler, the CloudNativePG operator, and a default dynamic StorageClass installed separately; `compute.backendName` set explicitly at install time |
 | `kind-self-contained.yaml` | Yes, on kind | KAI Scheduler and the CloudNativePG operator installed separately; `compute.backendName` set explicitly at install time |
+| `single-plane.yaml` | Base overlay | Site-specific external PostgreSQL, Valkey, and object-storage locations; required Kubernetes Secrets for static authentication; `externalUrl`; and `compute.backendName` |
 | `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 |
 
@@ -25,6 +26,20 @@ component, generated credentials, and embedded stateful dependencies. The split
 profiles contain example names and endpoints; copy them into an environment
 values file before installation.
 
+`single-plane.yaml` enables both planes with externally managed dependencies.
+It is provider-neutral and is not directly installable: layer it before a
+site-specific values file that supplies the required dependency locations and
+connection details. Object storage defaults to static Secret authentication;
+sites using a cloud SDK identity can set
+`externalDependencies.objectStorage.authentication.type: sdkDefault` instead.
+For example:
+
+```bash
+helm upgrade --install osmo deployments/charts/osmo \
+  --values deployments/charts/osmo/profiles/single-plane.yaml \
+  --values single-plane-azure.yaml
+```
+
 KAI Scheduler is a prerequisite for every profile that enables the compute
 plane. The unified chart does not install or manage KAI. CloudNativePG must also
 be installed before enabling the embedded PostgreSQL Cluster.

deployments/charts/osmo/profiles/quickstart.yaml

@@ -41,8 +41,12 @@ secrets:
       managedSecret:
         name: osmo-backend-token
   masterEncryptionKey:
-    generate: true
-    existingSecret: ''
+    managementMode: osmo
+    existingSecret:
+      name: osmo-mek
+      key: mek.yaml
+    bootstrap:
+      enabled: true
 
 services:
   ui: