Skip to content

test: migrate project-namespace-init from infra (WIP)#682

Draft
ecv wants to merge 1 commit into
mainfrom
test/migrate-project-namespace-init-from-infra
Draft

test: migrate project-namespace-init from infra (WIP)#682
ecv wants to merge 1 commit into
mainfrom
test/migrate-project-namespace-init-from-infra

Conversation

@ecv

@ecv ecv commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

WIP / DRAFT — migration in progress, do not merge yet.

What

Migrates the Project namespace-init Chainsaw test out of datum-cloud/infra into milo's local-env harness at test/resource-management/project-namespace-init/.

Flow: create Organization + User + OrganizationMembership → create Project in the org control plane → wait Ready → switch to the project control plane → assert the default namespace is Active → create + assert a ConfigMap and a Secret in it.

Why

Per datum-cloud/infra#3006, single-service API-contract tests are being evacuated from infra's live-env suite to their owning repos and run against milo's local apiserver pre-merge. This validates the resourcemanager.miloapis.com project-control-plane provisioning contract, which milo owns.

The infra original was permanently skip: true and depended on datumctl live-auth for both the org and project control planes.

Refs:

  • datum-cloud/infra#3006 (consolidation / evacuation)
  • datum-cloud/infra#3005

Adaptation from the infra original

  • Dropped both datumctl auth update-kubeconfig steps (org CP and project CP) and the live-auth kubeconfig plumbing.
  • Reaches the project control plane directly via the local apiserver URL-path subresource .../v1alpha1/projects/<project>/control-plane, matching the existing quota/multi-cluster-enforcement test which already provisions a project CP and writes a Secret to its default namespace.
  • Removed spec.skip: true; added Organization/User/OrganizationMembership fixtures; added a spec.description; zero inline comments per repo convention.

chainsaw lint: passes.

Known-uncertain

The local env DOES provision project control planes — confirmed: test/quota/multi-cluster-enforcement already creates a Project in the org CP, then targets .../projects/<name>/control-plane and creates a Secret in its default namespace. So this test was ported at full fidelity (default-namespace assertion + ConfigMap + Secret), not degraded.

Remaining uncertainty:

  • Timings (Ready 60s, default namespace Active 60s) mirror sibling tests but were not executed end-to-end in this branch (no live CI run performed — do not block on CI here).
  • If the project CP provisions default lazily/slower than the org namespace, the 60s wait on the namespace may need bumping.

Migrate the Project namespace-init contract test out of datum-cloud/infra
(infra#3006) into milo's local-env Chainsaw harness. The original
validated that a new Project's control plane is provisioned with a usable
default namespace; it ran against a live environment via datumctl and was
permanently skipped in infra. Milo owns the resourcemanager.miloapis.com
contract and its local env provisions project control planes, so the test
runs here pre-merge.

Key changes from the infra original:
- Drop the datumctl auth update-kubeconfig steps for both the org and the
  project control planes; reach the local org and project control planes
  directly via their apiserver URL-path subresources.
- Remove spec.skip; the local apiserver serves the project control plane
  and its default namespace.
- Set up Organization, User, and OrganizationMembership fixtures so the
  Project can be created in the org control plane.
- Assert the default namespace is Active in the project control plane,
  then create and assert a ConfigMap and Secret in it.
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