fix(controller): map NetworkPolicy to its GVR so agent provisioning isn't wedged (v0.10.0 blocker)#630
Closed
bussyjd wants to merge 1 commit into
Closed
fix(controller): map NetworkPolicy to its GVR so agent provisioning isn't wedged (v0.10.0 blocker)#630bussyjd wants to merge 1 commit into
bussyjd wants to merge 1 commit into
Conversation
…sn't wedged The agent-isolation NetworkPolicy was added to the agent manifest set, but resourceFor() had no case for kind=NetworkPolicy and fell through to the ConfigMap default. On a real apiserver that apply fails with 'NetworkPolicy in version v1 cannot be handled as a ConfigMap', which errors the whole agent reconcile BEFORE the remote-signer is provisioned — so a CRD-declared agent (obol agent new / obol sell agent) never gets a wallet, its offer never reaches Ready, and the 402 probe returns the storefront HTML. The default stack agent uses a different path with no netpol, which is why it was unaffected (flow-04 green, flow-16 red). Reproduced live on rc16. - Add monetizeapi.NetworkPolicyGVR and a resourceFor case for it. - Register NetworkPolicyGVR in the provisioning test harness (its absence is why a fake client tolerated the wrong GVR and unit tests stayed green). - TestResourceFor_NetworkPolicyUsesNetworkPolicyGVR asserts the object lands under the NetworkPolicy GVR, not ConfigMap. Verified live: agent Ready, remote-signer 1/1, netpol applied, wallet set; flow-16-sell-agent 15/0/0 and full release-smoke green. Security hardening intact (both hermes and signer are Ready WITH the netpol in place).
a574932 to
66c2257
Compare
Contributor
|
whats the difference between this pr and this one? #628 just a test? the case block looks unchanged. did you run the smoke on the latest rc17? |
Contributor
Author
|
Superseded by #628 (merged to main as |
OisinKyne
pushed a commit
that referenced
this pull request
Jun 12, 2026
…egression) main carries the fix (#628 / d16d167: NetworkPolicyGVR + the resourceFor case + the fake-client harness entry) but no test pinning it. Add TestResourceFor_NetworkPolicyUsesNetworkPolicyGVR, salvaged from the superseded #630, so a future refactor can't silently route the agent-isolation NetworkPolicy back to the ConfigMap default — a fake client tolerates the wrong GVR, which is how the rc16 regression hid.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
v0.10.0 release blocker — fixes agent-backed selling
The rc16 cut absorbed the #625 agent-isolation NetworkPolicy, but the controller's
resourceFor()had no case forNetworkPolicyand fell through to the ConfigMap default. On a real apiserver the apply fails:That error aborts the agent reconcile before the remote-signer is provisioned, so a CRD-declared agent (
obol agent new/obol sell agent) never gets a wallet, its offer never reachesReady, and the 402 probe returns storefront HTML. The default stack agent uses a different (netpol-free) path — which is exactly why flow-04 (default) was green but flow-16 (new agent) was red.Fix
monetizeapi.NetworkPolicyGVR+ aresourceForcase forNetworkPolicy.NetworkPolicyGVRin the provisioning test harness — its absence is why a fake client tolerated the wrong GVR and the unit tests stayed green through the regression.TestResourceFor_NetworkPolicyUsesNetworkPolicyGVRasserts the object lands under the NetworkPolicy GVR, not ConfigMap.Validation (live, on rc16 + this fix)
The #625 security hardening is intact, not relaxed — both Hermes and the signer are
Readywith the NetworkPolicy in place (the netpol does not block kubelet health probes).Do not publish v0.10.0 without this.