feat(service-catalog): require provider approval to enable compute#126
Open
scotwells wants to merge 1 commit into
Open
feat(service-catalog): require provider approval to enable compute#126scotwells wants to merge 1 commit into
scotwells wants to merge 1 commit into
Conversation
Set enablementPolicy.mode to GatedByProvider on the compute Service manifest so that new service enablements enter PendingApproval and require an explicit provider approval (spec.approval.decision: Approved) before becoming active, rather than self-activating immediately. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
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.
Summary
Enabling the Compute service now requires explicit provider approval. New consumers who enable the service will enter a
PendingApprovalstate and remain there until a provider setsspec.approval.decision: Approvedon theirServiceEntitlementorServiceConsumerrecord. Previously, the service self-activated immediately on enablement.The change is a single field added to the
computeServicemanifest inconfig/components/service-catalog/service.yaml:This sets
enablementPolicy.modefrom the implicit default (SelfService) toGatedByProvider, which is the valid enum value for provider-gated activation in the Milo service-catalog API (services.miloapis.com/v1alpha1 EnablementPolicy.Mode).Rollout impact
This policy change applies to new service enablements only. The
GatedByProvidermode gates the transition from no-entitlement to active; it does not retroactively re-evaluate or revoke entitlements that are already in anActivestate. ExistingServiceEntitlement/ServiceConsumerrecords — including thedatum-cloudproject — are expected to be unaffected by this manifest update.Reviewers should confirm this interpretation against the Milo service-catalog controller behavior for their deployment, as the exact semantics (whether the controller re-evaluates policy on existing active entitlements) are determined by the Milo control plane, not by this manifest alone. If there is any doubt, coordinate with the Milo team before merging to staging/production overlays.
Validation
kubectl kustomize config/components/service-catalogrenders cleanly with the new field present in theServiceoutput.🤖 Generated with Claude Code