Skip to content

fix(weave): share release-derived trace service account - #672

Open
nikumar1206 wants to merge 3 commits into
mainfrom
codex/weave-shared-service-account
Open

fix(weave): share release-derived trace service account#672
nikumar1206 wants to merge 3 commits into
mainfrom
codex/weave-shared-service-account

Conversation

@nikumar1206

@nikumar1206 nikumar1206 commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Derive the shared Weave Trace ServiceAccount from the Helm release name.
  • Have the trace workers reuse that account without creating component accounts.
  • Keep Azure workload-identity account selection unchanged.
  • Leave the separate base weave service unchanged.

Summary by CodeRabbit

  • New Features

    • Added support for sharing the Weave Trace service account across trace-related worker workloads.
    • Added configurable service account identity selection, enabled by default for trace, evaluation, and agent-scoring workers.
    • Automatically derives the shared service account from the release name.
  • Bug Fixes

    • Prevented duplicate service account creation when shared Weave Trace identity is enabled.
  • Chores

    • Updated Helm chart versions and bundled chart dependencies.

Comment thread charts/operator-wandb/values.yaml
@amwarrier

Copy link
Copy Markdown
Contributor

Confirmed how the four Weave-trace subcharts currently get their ServiceAccount: they're all aliases of wandb-base (see charts/operator-wandb/Chart.yaml:40-64) and resolve their SA through wandb-base.serviceAccountName in charts/wandb-base/templates/_helpers.tpl:87-95, which defaults to {{ .Release.Name }}-<alias> via wandb-base.fullname. With .Release.Name = wandb, weave-trace already produces wandb-weave-trace today — so the new weave-trace.serviceAccount block in this PR just restates the default and can be dropped.

The bigger issue: the three worker aliases hardcode name: wandb-weave-trace as a literal string. .Values.serviceAccount.name is not tpl'd by the helper, so '{{ .Release.Name }}-weave-trace' won't work as a values-side fix, and the current literal breaks the moment anyone deploys with a release name other than wandb.

Suggested design

Mirror the existing azureStorageServiceAccountEnabled / azureStorageServiceAccountName pattern already in charts/wandb-base/templates/_helpers.tpl — that helper is generic (backs every wandb-base-aliased subchart, not Weave-specific), and it already has one shared-SA short-circuit branch. Add a second one for Weave-trace:

1. In charts/wandb-base/templates/_helpers.tpl, add a new short-circuit branch and companion helper:

{{- define "wandb-base.serviceAccountName" -}}
  {{- if include "wandb-base.azureStorageServiceAccountEnabled" . | trim | eq "true" }}
{{- include "wandb-base.azureStorageServiceAccountName" . }}
  {{- else if .Values.serviceAccount.useWeaveTraceIdentity }}
{{- include "wandb-base.weaveTraceServiceAccountName" . }}
  {{- else if .Values.serviceAccount.create }}
{{- default (include "wandb-base.fullname" .) .Values.serviceAccount.name }}
  {{- else }}
{{- default "default" .Values.serviceAccount.name }}
  {{- end }}
{{- end }}

{{- define "wandb-base.weaveTraceServiceAccountName" -}}
{{- printf "%s-weave-trace" .Release.Name -}}
{{- end }}

2. In charts/wandb-base/templates/serviceaccount.yaml, extend the guard so opt-in workloads don't create their own SA:

{{- if and .Values.serviceAccount.create
      (not (include "wandb-base.azureStorageServiceAccountEnabled" . | trim | eq "true"))
      (not .Values.serviceAccount.useWeaveTraceIdentity) -}}

3. In charts/wandb-base/values.yaml, add the flag default:

serviceAccount:
  useWeaveTraceIdentity: false

4. In charts/operator-wandb/values.yaml, drop the weave-trace.serviceAccount block entirely, and on each of weave-trace-worker, weave-evaluate-model-worker, weave-trace-agent-scoring-worker set only:

serviceAccount:
  useWeaveTraceIdentity: true

No hardcoded name, no create: false — the helper handles both, and it stays correct regardless of .Release.Name.

Follow-up (not required for this PR)

Once all workers are on the shared SA, the three per-worker entries in internalJWTMap (-weave-trace-worker, -weave-evaluate-model-worker, -weave-trace-agent-scoring-worker) will be unused and can be removed. Keeping them during rollout is fine.

@coderabbitai coderabbitai Bot left a comment

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.

🧹 Nitpick comments (1)
charts/operator-wandb/tests/weave_trace_service_account_test.yaml (1)

37-93: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Test Azure identity priority with Weave Trace identity enabled.

The worker tests enable only useWeaveTraceIdentity. They do not cover the branch where Azure workload identity is also enabled. The helper selects wandb-bucket-access before the release-derived Trace ServiceAccount in that case.

Add a render test for one worker with valid Azure workload-identity values. Assert that the Pod uses the Azure shared ServiceAccount.

As per coding guidelines, “Exercise every meaningful branch in Helm templates with render or snapshot tests.”

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@charts/operator-wandb/tests/weave_trace_service_account_test.yaml` around
lines 37 - 93, Extend the worker render tests around the deployment assertions
to cover the branch where Weave Trace identity and Azure workload identity are
both enabled. Configure one worker with valid Azure workload-identity values,
then assert its Pod uses the shared wandb-bucket-access ServiceAccount,
preserving the existing release-derived identity tests for the non-Azure path.

Source: Coding guidelines

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@charts/operator-wandb/tests/weave_trace_service_account_test.yaml`:
- Around line 37-93: Extend the worker render tests around the deployment
assertions to cover the branch where Weave Trace identity and Azure workload
identity are both enabled. Configure one worker with valid Azure
workload-identity values, then assert its Pod uses the shared
wandb-bucket-access ServiceAccount, preserving the existing release-derived
identity tests for the non-Azure path.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 0de00d99-3060-438f-80fe-8693c562d1ad

📥 Commits

Reviewing files that changed from the base of the PR and between a95d4cd and 144f61e.

⛔ Files ignored due to path filters (4)
  • charts/lumen/Chart.lock is excluded by !**/*.lock
  • charts/operator-wandb/Chart.lock is excluded by !**/*.lock
  • charts/orchestrator/Chart.lock is excluded by !**/*.lock
  • test-configs/operator-wandb/__snapshots__/weave-trace-with-worker.snap is excluded by !**/*.snap
📒 Files selected for processing (10)
  • charts/lumen/Chart.yaml
  • charts/operator-wandb/Chart.yaml
  • charts/operator-wandb/tests/azure_storage_auth_test.yaml
  • charts/operator-wandb/tests/weave_trace_service_account_test.yaml
  • charts/operator-wandb/values.yaml
  • charts/orchestrator/Chart.yaml
  • charts/wandb-base/Chart.yaml
  • charts/wandb-base/templates/_helpers.tpl
  • charts/wandb-base/templates/serviceaccount.yaml
  • charts/wandb-base/values.yaml

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants