Skip to content

Local environment for testing IPAM against a real Milo control plane#49

Draft
scotwells wants to merge 1 commit into
mainfrom
feat/milo-integration-env
Draft

Local environment for testing IPAM against a real Milo control plane#49
scotwells wants to merge 1 commit into
mainfrom
feat/milo-integration-env

Conversation

@scotwells

@scotwells scotwells commented Jun 28, 2026

Copy link
Copy Markdown
Contributor

What & why

A reusable local environment that runs IPAM against a real, in-cluster Milo control plane, so we can exercise the full path the standalone e2e can't: delegated authn/authz, quota enforcement, and entitlement → grant → claim — on a single kind cluster.

It proves a project-scoped IPClaim both binds synchronously and is genuinely quota-enforced (a Milo ResourceClaim is granted, and the project's AllowanceBucket decrements):

IPClaim:         allocatedCIDR=10.200.0.0/24  phase=Bound
ResourceClaim:   GRANTED=True  reason=QuotaAvailable
AllowanceBucket: limit=100 allocated=1 available=99

What's here

  • config/overlays/milo-integration/ — additive overlay that turns on quota + Milo delegation (dev/test-infra overlays untouched), plus the quota primitives applied to Milo, tenant RBAC, task milo-integration:up, and docs/milo-integration.md (walkthrough + coverage vs the standalone e2e).

Notes for reviewers

  • Grant controllers run inside milo-controller-manager (no separate services-controller-manager in dev); this Milo build ships only raw quota.miloapis.com primitives, so the overlay reproduces the service-catalog effect directly.
  • Surfaced two IPAM-side issues (documented, not fixed here): ClaimCreationPolicy name templates must use requestInfo.name; an intermittent concurrent-map-write on the claim path.

Scope

Env/config only — no Go changes; internal/allocation/ stays zero-dep. No CI wiring yet. Draft: review the dev-token Secret approach before reuse against a shared Milo.

Adds a reusable local integration environment that runs the IPAM apiserver
wired to a real, in-cluster Milo control plane, so the full IPAM<->Milo path
can be exercised end-to-end: delegated authn/authz, quota enforcement, and the
entitlement -> grant -> claim chain. This is the path the standalone e2e
(--enable-quota=false, no Milo) cannot cover.

Artifacts:
- config/overlays/milo-integration/ — additive IPAM overlay (quota ON, all
  three delegation kubeconfig flags pointed at the in-cluster milo-apiserver
  via a Secret, NetworkPolicy egress to milo-system:6443). Dev/test-infra
  overlays are untouched.
- config/overlays/milo-integration/quota/ — quota.miloapis.com primitives
  applied to Milo (ResourceRegistration + ClaimCreationPolicy +
  GrantCreationPolicy) that register the IPAM quotable type and auto-create the
  per-project grant/bucket/claim. Reproduces what the services.miloapis.com
  catalog API would do — this Milo build ships only the raw quota primitives.
- config/overlays/milo-integration/rbac-tenant-user.yaml — Milo RBAC for the
  impersonated tenant user (IPAM delegates authz to Milo).
- Taskfile milo-integration:up (+ deploy-milo / deploy-ipam / provision-quota).
- docs/milo-integration.md — how to run it, the full-claim walkthrough, what it
  covers vs the standalone e2e, and known issues.

Verified end-to-end: an impersonated project-scoped IPClaim binds synchronously
(status.allocatedCIDR set) AND quota is enforced — a ResourceClaim is GRANTED
(reason QuotaAvailable) and the project AllowanceBucket decrements (alloc 1/100).

No Go changes; internal/allocation/ stays zero-dep and the forbidden-import
rules are intact. No CI workflow changes (follow-up).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@scotwells scotwells changed the title Local Milo integration environment: exercise the full IPAM↔Milo path Local environment for testing IPAM against a real Milo control plane Jun 29, 2026
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.

1 participant