Skip to content

Feature Request: Allow deployedResourceConstraint to evaluate resources in the management cluster #375

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
kahirokunn opened this issue May 9, 2025 · 0 comments

Comments

@kahirokunn
Copy link
Contributor

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: v1
  kind: ConfigMap
  name: central-customer-license
  namespace: licensing
  sourceClusterScope: 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

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

No branches or pull requests

1 participant