You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
In multi-cluster environments managed by Sveltos, we often want to deploy add-ons to member (workload) clusters only if a specific resource already exists in the management (hub) cluster.
Today, spec.deployedResourceConstraints can look only inside the candidate (workload) cluster itself, so we cannot express dependencies on management-cluster resources. As a result, platform teams must either duplicate configuration across clusters or rely on manual labeling—both error-prone and hard to automate.
Describe the solution you'd like
Extend DeployedResourceConstraint with an opt-in field (tentative name: sourceClusterScope) that tells the Classifier where to evaluate the resource:
deployedResourceConstraints:
- group: ""version: v1kind: ConfigMapname: central-customer-licensenamespace: licensingsourceClusterScope: Local # new enum: Current (default) | Local
Current (default) → keeps today’s behavior (evaluate inside each candidate cluster).
Local → evaluates the constraint against the mgmt cluster once; the result then drives labeling for every candidate cluster.
If the constraint matches, the Classifier labels the workload cluster as usual, allowing a ClusterProfile to select and install the desired resources.
Describe alternatives you've considered
Copy the resource into every workload cluster via a separate controller or sync job – increases drift risk and network traffic.
Pre-label workload clusters manually – does not adapt to changes, adds operational overhead.
External scripting to call the k8s API and patch labels
Additional context
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
In multi-cluster environments managed by Sveltos, we often want to deploy add-ons to member (workload) clusters only if a specific resource already exists in the management (hub) cluster.
Today,
spec.deployedResourceConstraints
can look only inside the candidate (workload) cluster itself, so we cannot express dependencies on management-cluster resources. As a result, platform teams must either duplicate configuration across clusters or rely on manual labeling—both error-prone and hard to automate.Describe the solution you'd like
Extend
DeployedResourceConstraint
with an opt-in field (tentative name:sourceClusterScope
) that tells the Classifier where to evaluate the resource:If the constraint matches, the Classifier labels the workload cluster as usual, allowing a
ClusterProfile
to select and install the desired resources.Describe alternatives you've considered
Additional context
The text was updated successfully, but these errors were encountered: