feat: feature-flagging via Milo entitlements (#577)#695
Open
kevwilliams wants to merge 4 commits into
Open
Conversation
Add provisional enhancement for org-level boolean feature flags built on the existing quota.miloapis.com entitlement primitives. v1 is zero-code: ResourceRegistration defines a flag, ResourceGrant enables it for an org, AllowanceBucket is the read path for services. No new CRDs, controllers, or binary changes required.
Contributor
|
@kevwilliams the registration path looks okay, the type being |
- Resolve consumer check strategy: adopt OpenFeature-compatible provider (Go + TypeScript) wrapping AllowanceBucket field selector query so services never call the quota API directly - Add type=Feature as a hard prerequisite: live CRD only accepts Entity and Allocation; spec.type is immutable so the Milo enum change must land before any ResourceRegistration instances are created - Replace three-option consumer API with OpenFeature provider contract, usage examples, and deliverables - Add custom SDK alternative to Alternatives section - Resolve open question 2 (consumer check strategy); renumber remaining
Author
|
@scotwells Updated it to include these things, also considered the rolling our own idea a bit, I think OpenFeature gives us quite a bit for free there so I included that in there too. |
- Resolve claimingResources: minItems=1 enforced; adopt sentinel features.miloapis.com/FeatureGrant to satisfy constraint - Resolve bundle vs infra: ResourceRegistrations in Milo bundle; ResourceGrants in datum-cloud/infra for per-cluster variation - Resolve IAM role: dedicated feature-flag-operator, not quota-operator - Resolve naming: features.miloapis.com/<name> confirmed - Resolve org admin read: organization-quota-manager already sufficient - Promote status from provisional to implementable
This was referenced Apr 27, 2026
Closed
scotwells
previously approved these changes
Apr 27, 2026
This was referenced May 4, 2026
kevwilliams
added a commit
to milo-os/milo
that referenced
this pull request
May 5, 2026
## Summary - Adds `Feature` as a valid value for `spec.type` on `ResourceRegistration`, alongside the existing `Entity` and `Allocation` values - `Feature` is a boolean entitlement grant for org-level feature flags — no admission enforcement or claim machinery is used; the registration simply signals that a feature is available to an organization - Regenerates the CRD YAML (`quota.miloapis.com_resourceregistrations.yaml`) so the new enum value is enforced at the API level - Adds a Chainsaw test step (`create-valid-feature-registration`) to verify that `type=Feature` is accepted and the registration reaches `Active=True` No controller logic branches on `spec.type` — grep confirms zero usages of `registration.Spec.Type` in `internal/quota/`. This is a schema/validation-only change. The field is immutable after creation (CEL rule already in place). Closes #575 Related: datum-cloud/enhancements#695 ## Test plan - [ ] `task generate:code` runs cleanly and `Feature` appears in `config/crd/bases/quota/quota.miloapis.com_resourceregistrations.yaml` enum - [ ] Chainsaw test `create-valid-feature-registration` passes: creates a `ResourceRegistration` with `type: Feature` and waits for `Active=True` - [ ] Existing Chainsaw tests (`test-invalid-type-enum`, immutability tests, etc.) continue to pass - [ ] Attempting to create a registration with an invalid type still returns an error mentioning `spec.type`
This was referenced May 5, 2026
quota.miloapis.com-manager already covers all permissions needed to manage feature flags — no dedicated feature-flag-operator role needed. Also drop the iam/ subtree from the Bootstrap Configuration example since no new role is being added.
3 tasks
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
2 participants
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.
Summary
Adds a provisional enhancement for org-level boolean feature flags built entirely on the existing
quota.miloapis.com/v1alpha1primitives.What this proposes
ResourceRegistrationwithtype=EntityResourceGrantwithamount=1targeting an orgAllowanceBucket.status.available > 0queried by field selectorKey decisions needed from reviewers
The doc marks six open questions with
<<[UNRESOLVED]>>blocks. The two blocking ones:claimingResourcesvalidation — the CRD schema may enforceMinItems=1, which would break the proposedResourceRegistrationshape. Needs verification against the live CRD before this can move toimplementable.AllowanceBucket(Option A) as the standard read path, or prefer queryingResourceGrantdirectly (Option B).Test plan
claimingResources: []is accepted by the liveResourceRegistrationCRDResourceRegistrationandResourceGrantYAML to a dev cluster and confirmAllowanceBucketis auto-createdAllowanceBucket.status.availabledrops to 0 afterResourceGrantdeletionAllowanceBucketswith existingorganization-quota-managerrole