Skip to content

feat: add discovery context annotations for project-scoped resources - #138

Open
scotwells wants to merge 2 commits into
mainfrom
feat/discovery-context-annotations
Open

feat: add discovery context annotations for project-scoped resources#138
scotwells wants to merge 2 commits into
mainfrom
feat/discovery-context-annotations

Conversation

@scotwells

Copy link
Copy Markdown
Contributor

Summary

  • Adds discovery.miloapis.com/parent-contexts: Project annotation to all 13 CRD manifests in config/crd/bases/
  • Adds +kubebuilder:metadata:annotations="discovery.miloapis.com/parent-contexts=Project" kubebuilder marker to all 13 top-level Go resource types

Why

The Milo API server includes a discovery filter that controls which resources appear in API discovery responses based on the current request context (Platform, Organization, Project, or User). By annotating all networking resources with parent-contexts: Project, they will only appear in discovery responses when a client queries within a Project's control plane — keeping the API surface clean and contextually appropriate.

Affected CRDs

networking.datumapis.com (v1alpha)

  • Domain
  • HTTPProxy
  • Location
  • Network
  • NetworkBinding
  • NetworkContext
  • NetworkPolicy
  • Subnet
  • SubnetClaim
  • TrafficProtectionPolicy

networking.datumapis.com (v1alpha1)

  • Connector
  • ConnectorAdvertisement
  • ConnectorClass

Notes

The kubebuilder markers were added to the non-List resource types only (i.e., the types with +kubebuilder:subresource:status). The CRD YAML files were updated directly to match what controller-gen would produce when regenerating from the updated Go markers.

scotwells and others added 2 commits April 18, 2026 08:57
All networking resources are scoped to the Project discovery context.
This controls which resources appear in API discovery when querying
within a project's control plane.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@scotwells
scotwells requested review from a team and JoseSzycho May 5, 2026 21:17
@scotwells
scotwells marked this pull request as ready for review May 5, 2026 21:32

@kevwilliams kevwilliams left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Naming and value format match the established convention (discovery.miloapis.com/parent-contexts, compare compute and dns-operator repos), and RBAC/tests are correctly out of scope since this is static CRD/kubebuilder metadata, not runtime behavior.

One scoping concern: Location is cluster-scoped (kubebuilder:resource:scope=Cluster) but is tagged parent-contexts=Project only. Unlike ConnectorClass here, which matches the existing DNSZoneClass precedent of a cluster-scoped "class" companion type getting Project-only visibility, Location is the primary resource representing shared infrastructure (a datacenter/region), not a per-project owned object. The other cluster-scoped precedent in the org, RuntimeClass in compute, uses parent-contexts=Platform,Project rather than Project alone.

Should Location also include Platform in parent-contexts so it stays visible outside a project control plane, or is Project-only intentional here? Worth confirming before merge since this affects where the resource shows up in discovery.

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.

3 participants