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]>
3.3 KiB
3.3 KiB
date, branch, title
| date | branch | title |
|---|---|---|
| 2026-10-31 | chore/pm-agent-go-live | 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 lackedimagePullSecrets) 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.mdanddocs/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.mdis unchanged. Its "stop it: setPM_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, includingworker-pull-secret-must-be-the-committed-one. - RBAC: ServiceAccounts
pm-agentandpm-agent-worker, Rolepm-agentand RoleBindingpm-agent(roleRefpm-agent, subjectServiceAccount/pm-agent) all exist.auth can-iassystem:serviceaccount:pm-agent:pm-agentreturnedyesforcreate jobs.batchandnofordelete jobs.batch. - Secrets (key names only):
pm-agent-registryiskubernetes.io/dockerconfigjsonwith key.dockerconfigjson.pm-agent-credentialsisOpaquewith keysclaude-code-oauth-tokenandgitea-token. - Egress:
default-denyNetworkPolicy exists. CiliumNetworkPoliciespm-agent-allow-egressandpm-agent-worker-allow-egressboth reportValid=True. - Deployment
pm-agentis 1/1 onagent-runner@sha256:df36d9b7…withconfig-generation: "3"live. No Jobs exist in the namespace. platform/pm-agent/{configmap,deployment}.yaml, README and docs do not match anysensitive_pathsglob ininfra/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
startdecision 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-settingsnot run.