From 9c22d08f560da7d2af57efa903517ffe37256703 Mon Sep 17 00:00:00 2001 From: Prashanth K Nalubandhu Date: Tue, 7 Jul 2026 12:02:58 -0400 Subject: [PATCH 1/3] Document how to apply config changes on self-managed (restart or Reloader) Config/auth changes update the ConfigMaps but don't restart the running pods, so changes (SSO/OIDC especially) look like they didn't take effect. Add a section explaining you need to restart app/api or install Stakater Reloader. --- platform/hosting/self-managed/operator.mdx | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/platform/hosting/self-managed/operator.mdx b/platform/hosting/self-managed/operator.mdx index a40d197787..c6bc20c134 100644 --- a/platform/hosting/self-managed/operator.mdx +++ b/platform/hosting/self-managed/operator.mdx @@ -238,6 +238,24 @@ For detailed instructions on using these cloud-specific modules, see [Deploy wit +## Applying configuration changes + +When you change configuration after the initial install — for example SSO/OIDC settings, environment variables, or other values in the custom resource (CR) — the operator updates the underlying ConfigMaps, but the running pods do not automatically pick up the change. Kubernetes does not restart pods when a mounted ConfigMap changes. + +Apply the change in one of two ways: + +- **Restart the affected deployments manually.** Restart whichever components consume the changed config; `app` and `api` cover most auth/SSO changes: + + ```bash + kubectl -n rollout restart deployment/-app deployment/-api + ``` + +- **Install [Stakater Reloader](https://github.com/stakater/Reloader).** The chart already annotates the deployments with `reloader.stakater.com/auto: "true"`, so if the Reloader controller is running in your cluster it restarts the affected pods automatically when their ConfigMap or Secret changes. Reloader is not installed by default, so on a fresh cluster you must deploy it yourself for this to work. + + +If you change SSO/OIDC settings and login still behaves the same, it is almost always because the pods are still running the old config. Restart `app` and `api` (or install Reloader), then try again. + + ## Enable the MCP server The [W&B MCP Server](/platform/mcp-server) ships as an optional subchart in `operator-wandb`. When enabled, the operator deploys an in-cluster MCP server exposed through your existing ingress at `/mcp`, so any MCP-compatible client can connect using a W&B API key. This is the same server W&B runs as the hosted offering at `https://mcp.withwandb.com/mcp`, but pointed at your deployment's data. From 6c9470f7a78babf5c1f9bac541ad4f42efa7d100 Mon Sep 17 00:00:00 2001 From: Prashanth K Nalubandhu Date: Tue, 7 Jul 2026 15:20:19 -0400 Subject: [PATCH 2/3] Make the restart command discover deployment names first Review feedback: hardcoded names (-app / -api) don't match the default chart, where the app deployment carries a -bc suffix and names vary by version/install. List deployments first, then restart the right ones. --- platform/hosting/self-managed/operator.mdx | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/platform/hosting/self-managed/operator.mdx b/platform/hosting/self-managed/operator.mdx index c6bc20c134..d570400897 100644 --- a/platform/hosting/self-managed/operator.mdx +++ b/platform/hosting/self-managed/operator.mdx @@ -244,10 +244,11 @@ When you change configuration after the initial install — for example SSO/OIDC Apply the change in one of two ways: -- **Restart the affected deployments manually.** Restart whichever components consume the changed config; `app` and `api` cover most auth/SSO changes: +- **Restart the affected deployments manually.** Deployment names vary by version and install (the app deployment usually carries a `-bc` suffix, e.g. `-app-bc`), so list them first, then restart the ones that consume the changed config — the `app` component covers most auth/SSO changes: ```bash - kubectl -n rollout restart deployment/-app deployment/-api + kubectl -n get deployments + kubectl -n rollout restart deployment/ # e.g. -app-bc ``` - **Install [Stakater Reloader](https://github.com/stakater/Reloader).** The chart already annotates the deployments with `reloader.stakater.com/auto: "true"`, so if the Reloader controller is running in your cluster it restarts the affected pods automatically when their ConfigMap or Secret changes. Reloader is not installed by default, so on a fresh cluster you must deploy it yourself for this to work. From 462b383b58103a448de7742fe36c00522bd3c233 Mon Sep 17 00:00:00 2001 From: John Mulhausen Date: Thu, 9 Jul 2026 13:00:44 -0400 Subject: [PATCH 3/3] Polish added content per Google Developer Style Guide --- platform/hosting/self-managed/operator.mdx | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/platform/hosting/self-managed/operator.mdx b/platform/hosting/self-managed/operator.mdx index d570400897..e4803df4b9 100644 --- a/platform/hosting/self-managed/operator.mdx +++ b/platform/hosting/self-managed/operator.mdx @@ -238,23 +238,23 @@ For detailed instructions on using these cloud-specific modules, see [Deploy wit -## Applying configuration changes +## Apply configuration changes -When you change configuration after the initial install — for example SSO/OIDC settings, environment variables, or other values in the custom resource (CR) — the operator updates the underlying ConfigMaps, but the running pods do not automatically pick up the change. Kubernetes does not restart pods when a mounted ConfigMap changes. +After the initial install, you can change SSO/OIDC settings, environment variables, or other values in the custom resource (CR). When you do, the operator updates the underlying ConfigMaps, but the running pods don't automatically pick up the change. Kubernetes doesn't restart pods when a mounted ConfigMap changes. Apply the change in one of two ways: -- **Restart the affected deployments manually.** Deployment names vary by version and install (the app deployment usually carries a `-bc` suffix, e.g. `-app-bc`), so list them first, then restart the ones that consume the changed config — the `app` component covers most auth/SSO changes: +- **Restart the affected deployments manually.** Deployment names vary by version and install (the app deployment usually carries a `-bc` suffix, for example `-app-bc`). The `app` component covers most auth/SSO changes. List the deployments first, then restart the ones that consume the changed config: ```bash kubectl -n get deployments kubectl -n rollout restart deployment/ # e.g. -app-bc ``` -- **Install [Stakater Reloader](https://github.com/stakater/Reloader).** The chart already annotates the deployments with `reloader.stakater.com/auto: "true"`, so if the Reloader controller is running in your cluster it restarts the affected pods automatically when their ConfigMap or Secret changes. Reloader is not installed by default, so on a fresh cluster you must deploy it yourself for this to work. +- **Install [Stakater Reloader](https://github.com/stakater/Reloader).** The chart already annotates the deployments with `reloader.stakater.com/auto: "true"`. If the Reloader controller is running in your cluster, it restarts the affected pods automatically when their ConfigMap or Secret changes. Reloader isn't installed by default, so on a fresh cluster you must deploy it yourself for this to work. -If you change SSO/OIDC settings and login still behaves the same, it is almost always because the pods are still running the old config. Restart `app` and `api` (or install Reloader), then try again. +If you change SSO/OIDC settings and login still behaves the same, it's almost always because the pods are still running the old config. Restart `app` and `api` (or install Reloader), then try again. ## Enable the MCP server