docs: move referenced-data delivery to Karmada native dependency propagation#156
Open
scotwells wants to merge 1 commit into
Open
docs: move referenced-data delivery to Karmada native dependency propagation#156scotwells wants to merge 1 commit into
scotwells wants to merge 1 commit into
Conversation
…agation Shared ConfigMaps/Secrets should follow a workload to every location it runs. The original hub-to-cell design — companion selectors on each city's routing policy — cannot do that: Karmada policy claiming is exclusive, so a companion shared across cities is delivered to exactly one of them and instances elsewhere wait forever (#155). This revision moves delivery to Karmada's native dependency propagation: propagateDeps on the deployment's placement policy plus a declarative dependency-interpretation hook that reads the resolver's expected companion set. Each companion's attached binding inherits the union of every referencing deployment's destinations, so the single-claimant failure dimension is removed rather than patched. Unchanged: the management-plane resolver, the companion objects and annotation contract, the cell-side scheduling gate, and rotation. New design requirements recorded: hub Karmada >= v1.15.3 (karmada-io/karmada#6931), the PropagateDeps feature gate, webhook protection for the now propagation-authorizing annotation, and downstream annotation mirroring on removal. Co-Authored-By: Claude Fable 5 <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
1 participant
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.
What this changes for users
Shared configuration can follow workloads to every location that needs it. Today, a ConfigMap/Secret referenced by workloads in two or more cities is delivered to exactly one — instances elsewhere wait on data that never arrives, with no error raised (#155). This design revision removes that single-location limitation structurally instead of patching it.
What this PR is
A revision of the referenced ConfigMap/Secret delivery design doc (
configmap-secret-mounts.md) — no implementation. Implementation is tracked in #155; the current per-city delivery path (#129) stays behind a single-city validation guard until this lands.The hub-to-cell mechanism moves from per-city routing-policy selectors to Karmada's native dependency propagation:
propagateDepson the deployment's placement policy plus a declarative dependency-interpretation hook that reads the resolver's expected companion set. Each companion's destinations become the union of every referencing deployment's placements — and delivery stays scoped to cells that actually run a referencing workload. The resolver, companion objects, scheduling gate, and rotation are unchanged.Key prerequisites (recorded as design requirements)
PropagateDepsfeature gate enabled on the hub (opt-in per policy; no effect on other tenants)🤖 Generated with Claude Code