Skip to content
Open
Changes from 1 commit
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
18 changes: 18 additions & 0 deletions platform/hosting/self-managed/operator.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -238,6 +238,24 @@ For detailed instructions on using these cloud-specific modules, see [Deploy wit

<SelfManagedVerifyInstallation/>

## 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 <namespace> rollout restart deployment/<release>-app deployment/<release>-api

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Partially confirmed — the approach (restart the affected deployments) is confirmed, but these deployment names don't match the operator's default chart, so this command errors with NotFound on a default install.

On the current operator-wandb chart the app deployment renders as <release>-app-bc (deploymentPostfix: "bc" is the default), and there is no standalone <release>-api deploymentapi is a ConfigMap that the app (wandb/local) deployment consumes, so restarting app applies the API/SSO config too. Names also vary by install method/version.

Suggested change
kubectl -n <namespace> rollout restart deployment/<release>-app deployment/<release>-api
# Deployment names vary by chart version/install. On the operator's default chart the
# app deployment is <release>-app-bc, and there is no separate <release>-api deployment
# (the app deployment serves the API and consumes the SSO/OIDC config). List them first:
kubectl -n <namespace> get deployments
kubectl -n <namespace> rollout restart deployment/<release>-app-bc

Source: operator-wandb/values.yaml#L748-L750, wandb-base/_helpers.tpl#L26-L29, default.snap#L2830-L2834 · Recommended: confirm the canonical operator deployment names with @pnalubandhu-a11y (the OCP 4.21 test — were they <release>-app/<release>-api or -bc?).

🤖 CoreWeave Docs Team's Validator — partially confirmed

```

- **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.

<Note>
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.
</Note>

## 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 `<global.host>/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.
Expand Down
Loading