jakman85andClaude Opus 5.5
0d3e51acc4
The run-383 worker image (df36d9b, pinned in #96) bakes imagePullSecrets: pm-agent-registry, which admission requires, and the dispatcher's dry-run triage of #97 was read and approved. PM_REQUIRE_LABEL=agent and the worker caps are unchanged. The dry-run status text in the configmap comments, the README and the plan's follow-up 3 is updated to match. Pre-flight (read-only, k3s-prod): pm-agent-job-shape Ready+Enforce; SA/Role/RoleBinding present and can-i create jobs = yes; pm-agent-registry and pm-agent-credentials exist; both egress CNPs Valid. Co-Authored-By: Claude Opus 5.5 <[email protected]>
56 lines
3.3 KiB
Markdown
56 lines
3.3 KiB
Markdown
---
|
|
date: 2026-10-31
|
|
branch: chore/pm-agent-go-live
|
|
title: Take pm-agent out of dry run (operator-approved); label scope and worker caps unchanged
|
|
---
|
|
|
|
## What changed
|
|
|
|
- `platform/pm-agent/configmap.yaml`: `PM_DRY_RUN` `"true"` -> `"false"`. The operator approved
|
|
this after reading the dry-run triage of issue #97. `PM_REQUIRE_LABEL: agent`,
|
|
`PM_MAX_ACTIVE_WORKERS: 2`, `PM_MAX_NEW_WORKERS_PER_CYCLE: 1`, the worker image digest and every
|
|
other knob are unchanged. The two comments that said dry run was the only mode that worked
|
|
(because the run-340 digest lacked `imagePullSecrets`) now describe the run-383 digest that
|
|
PR #96 pinned.
|
|
- `platform/pm-agent/deployment.yaml`: `config-generation` `"3"` -> `"4"`. Without the bump the
|
|
dispatcher keeps its startup config and stays in dry run.
|
|
- `platform/pm-agent/README.md` and `docs/plans/pm-agent-issue-to-pr.md` (follow-up 3): the
|
|
"currently dry run" status text now says dry run is off. `runbooks/pm-agent.md` is unchanged.
|
|
Its "stop it: set `PM_DRY_RUN: "true"`" step and its admission-refusal troubleshooting row
|
|
are still accurate.
|
|
|
|
## What I verified
|
|
|
|
Read-only, `kubectl --context k3s-prod` through the toolbox, 2026-10-31 ~11:45 local, with Flux
|
|
`pm-agent` and `platform-config` both at `main@1126740`:
|
|
|
|
- ClusterPolicy `pm-agent-job-shape`: `Ready=True`, `validationFailureAction=Enforce`,
|
|
`background=false`. It has seven rules, including `worker-pull-secret-must-be-the-committed-one`.
|
|
- RBAC: ServiceAccounts `pm-agent` and `pm-agent-worker`, Role `pm-agent` and RoleBinding
|
|
`pm-agent` (roleRef `pm-agent`, subject `ServiceAccount/pm-agent`) all exist. `auth can-i`
|
|
as `system:serviceaccount:pm-agent:pm-agent` returned `yes` for `create jobs.batch` and `no`
|
|
for `delete jobs.batch`.
|
|
- Secrets (key names only): `pm-agent-registry` is `kubernetes.io/dockerconfigjson` with key
|
|
`.dockerconfigjson`. `pm-agent-credentials` is `Opaque` with keys `claude-code-oauth-token`
|
|
and `gitea-token`.
|
|
- Egress: `default-deny` NetworkPolicy exists. CiliumNetworkPolicies `pm-agent-allow-egress`
|
|
and `pm-agent-worker-allow-egress` both report `Valid=True`.
|
|
- Deployment `pm-agent` is 1/1 on `agent-runner@sha256:df36d9b7…` with
|
|
`config-generation: "3"` live. No Jobs exist in the namespace.
|
|
- `platform/pm-agent/{configmap,deployment}.yaml`, README and docs do not match any
|
|
`sensitive_paths` glob in `infra/gitea/approval-policy.json`, so no review or override applies.
|
|
|
|
## What I did NOT verify
|
|
|
|
- **That a real worker Job is admitted and completes.** Nothing can show this until a labelled
|
|
issue gets a `start` decision after the merge. The L0 Kyverno suite shows the policy accepts
|
|
the committed template. Whether the API server admits the Job built from the df36d9b image's
|
|
baked template has not been tested live.
|
|
- That the worker pod can pull its image with `pm-agent-registry`, reach Gitea and the model
|
|
through its egress policy, and push a branch and open a PR. None of this has run before.
|
|
- The pod list also shows a stale `pm-agent-65db599649-v678g` (25d, `ContainerStatusUnknown`,
|
|
from an old ReplicaSet). It does not block anything, but I did not investigate it. Clearing
|
|
it is an operator action.
|
|
- CI: see the PR for the gate result. Locally the best possible result is rc 3, with only
|
|
`gitea-settings` not run.
|