Skip to content
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

ClusterProfile installing multiple Helm charts does not update clusterconfigurations in case of failures #305

Closed
gianlucam76 opened this issue Aug 20, 2023 · 1 comment
Labels
bug Something isn't working help wanted Extra attention is needed

Comments

@gianlucam76
Copy link
Member

gianlucam76 commented Aug 20, 2023

If a ClusterProfile is listing more than one Helm charts, and some are installed before an error happens, the installed Helm charts are not reported.

For instance, deploy following ClusterProfile

apiVersion: config.projectsveltos.io/v1alpha1
kind: ClusterProfile
metadata:
  name: multiple-helm-charts
spec:
  clusterSelector: env=fv
  syncMode: Continuous
  helmCharts:
  - repositoryURL:    https://prometheus-community.github.io/helm-charts
    repositoryName:   prometheus-community
    chartName:        prometheus-community/prometheus
    chartVersion:     23.4.0
    releaseName:      prometheus
    releaseNamespace: prometheus
    helmChartAction:  Install
  - repositoryURL:    https://grafana.github.io/helm-charts
    repositoryName:   bitnami
    chartName:        grafana/grafana
    chartVersion:     6.58.9
    releaseName:      grafana
    releaseNamespace: grafana
    helmChartAction:  Install

Prometheus gets installed. Grafana does not (as repositoryName is incorrectly set). Yet ClusterConfiguration does not list Prometheus as installed

  apiVersion: config.projectsveltos.io/v1alpha1
  kind: ClusterConfiguration
  metadata:
    creationTimestamp: "2023-08-20T14:27:28Z"
    generation: 1
    labels:
      projectsveltos.io/cluster-name: clusterapi-workload
      projectsveltos.io/cluster-type: Capi
    name: capi--clusterapi-workload
    namespace: default
    ownerReferences:
    - apiVersion: config.projectsveltos.io/v1alpha1
      kind: ClusterProfile
      name: multiple-helm-charts
      uid: 634678b8-ff6f-479c-acae-de5dd50ab0c2
    resourceVersion: "20595"
    uid: 8b2db1ac-cfdc-418b-a5ec-e20fce064179
  status:
    clusterProfileResources:
    - clusterProfileName: multiple-helm-charts

same is visible with

kubectl exec -it -n projectsveltos sveltosctl-0 -- ./sveltosctl show addons 
+---------+---------------+-----------+------+---------+------+------------------+
| CLUSTER | RESOURCE TYPE | NAMESPACE | NAME | VERSION | TIME | CLUSTER PROFILES |
+---------+---------------+-----------+------+---------+------+------------------+
+---------+---------------+-----------+------+---------+------+------------------+
@gianlucam76 gianlucam76 added bug Something isn't working help wanted Extra attention is needed labels Aug 20, 2023
@gianlucam76
Copy link
Member Author

Correct ClusterProfile is

apiVersion: config.projectsveltos.io/v1alpha1
kind: ClusterProfile
metadata:
  name: multiple-helm-charts
spec:
  clusterSelector: env=fv
  syncMode: Continuous
  helmCharts:
  - repositoryURL:    https://prometheus-community.github.io/helm-charts
    repositoryName:   prometheus-community
    chartName:        prometheus-community/prometheus
    chartVersion:     23.4.0
    releaseName:      prometheus
    releaseNamespace: prometheus
    helmChartAction:  Install
  - repositoryURL:    https://grafana.github.io/helm-charts
    repositoryName:   grafana
    chartName:        grafana/grafana
    chartVersion:     6.58.9
    releaseName:      grafana
    releaseNamespace: grafana
    helmChartAction:  Install

gianlucam76 pushed a commit to gianlucam76/addon-controller that referenced this issue May 13, 2024
gianlucam76 pushed a commit to gianlucam76/addon-controller that referenced this issue May 14, 2024
ClusterProfile/Profile instances let deploy add-ons and applications
(Helm charts or Kubernetes resources) across a set of managed clusters.

Sometimes there might be a need to tweak deployments for specific clusters
(a subset of the original group) within that group.

Previously, creating a new ClusterProfile/Profile targeting a subset of clusters
with resources already managed by another profile resulted in conflicts.
Sveltos wouldn't allow deployment for those resources.

The concept of ```tier``` is introduced to manage deployment priority for
resources targeted by multiple configurations.

How it works:

1. Each ClusterProfile/Profile has a new property called __tier__.
2. This tier value controls the deployment order for resources targeting
the same cluster element (e.g., a Kubernetes object or Helm chart).
3. By default, the first configuration to reach the cluster "wins" and deploys the resource.
4. Tiers override this behavior. When conflicts occur, the configuration with the lowest tier
value takes precedence and deploys the resource. Higher tier values represent lower priority.
5. The default tier value is 100.

Benefits:

1. Finer control over resource deployment: Tiers allow you to fine-tune deployments within
your cluster, especially when multiple configurations manage the same resources.
2. Conflict resolution: Tiers ensure predictable outcomes when multiple configurations target
the same resource. The configuration with the most critical deployment (lowest tier) takes priority.

Fixes projectsveltos#305
gianlucam76 pushed a commit to gianlucam76/addon-controller that referenced this issue May 14, 2024
ClusterProfile/Profile instances let deploy add-ons and applications
(Helm charts or Kubernetes resources) across a set of managed clusters.

Sometimes there might be a need to tweak deployments for specific clusters
(a subset of the original group) within that group.

Previously, creating a new ClusterProfile/Profile targeting a subset of clusters
with resources already managed by another profile resulted in conflicts.
Sveltos wouldn't allow deployment for those resources.

The concept of ```tier``` is introduced to manage deployment priority for
resources targeted by multiple configurations.

How it works:

1. Each ClusterProfile/Profile has a new property called __tier__.
2. This tier value controls the deployment order for resources targeting
the same cluster element (e.g., a Kubernetes object or Helm chart).
3. By default, the first configuration to reach the cluster "wins" and deploys the resource.
4. Tiers override this behavior. When conflicts occur, the configuration with the lowest tier
value takes precedence and deploys the resource. Higher tier values represent lower priority.
5. The default tier value is 100.

Benefits:

1. Finer control over resource deployment: Tiers allow you to fine-tune deployments within
your cluster, especially when multiple configurations manage the same resources.
2. Conflict resolution: Tiers ensure predictable outcomes when multiple configurations target
the same resource. The configuration with the most critical deployment (lowest tier) takes priority.

Fixes projectsveltos#305
gianlucam76 pushed a commit to gianlucam76/addon-controller that referenced this issue May 14, 2024
ClusterProfile/Profile instances let deploy add-ons and applications
(Helm charts or Kubernetes resources) across a set of managed clusters.

Sometimes there might be a need to tweak deployments for specific clusters
(a subset of the original group) within that group.

Previously, creating a new ClusterProfile/Profile targeting a subset of clusters
with resources already managed by another profile resulted in conflicts.
Sveltos wouldn't allow deployment for those resources.

The concept of ```tier``` is introduced to manage deployment priority for
resources targeted by multiple configurations.

How it works:

1. Each ClusterProfile/Profile has a new property called __tier__.
2. This tier value controls the deployment order for resources targeting
the same cluster element (e.g., a Kubernetes object or Helm chart).
3. By default, the first configuration to reach the cluster "wins" and deploys the resource.
4. Tiers override this behavior. When conflicts occur, the configuration with the lowest tier
value takes precedence and deploys the resource. Higher tier values represent lower priority.
5. The default tier value is 100.

Benefits:

1. Finer control over resource deployment: Tiers allow you to fine-tune deployments within
your cluster, especially when multiple configurations manage the same resources.
2. Conflict resolution: Tiers ensure predictable outcomes when multiple configurations target
the same resource. The configuration with the most critical deployment (lowest tier) takes priority.

Fixes projectsveltos#305
gianlucam76 pushed a commit to gianlucam76/addon-controller that referenced this issue May 14, 2024
ClusterProfile/Profile instances let deploy add-ons and applications
(Helm charts or Kubernetes resources) across a set of managed clusters.

Sometimes there might be a need to tweak deployments for specific clusters
(a subset of the original group) within that group.

Previously, creating a new ClusterProfile/Profile targeting a subset of clusters
with resources already managed by another profile resulted in conflicts.
Sveltos wouldn't allow deployment for those resources.

The concept of ```tier``` is introduced to manage deployment priority for
resources targeted by multiple configurations.

How it works:

1. Each ClusterProfile/Profile has a new property called __tier__.
2. This tier value controls the deployment order for resources targeting
the same cluster element (e.g., a Kubernetes object or Helm chart).
3. By default, the first configuration to reach the cluster "wins" and deploys the resource.
4. Tiers override this behavior. When conflicts occur, the configuration with the lowest tier
value takes precedence and deploys the resource. Higher tier values represent lower priority.
5. The default tier value is 100.

Benefits:

1. Finer control over resource deployment: Tiers allow you to fine-tune deployments within
your cluster, especially when multiple configurations manage the same resources.
2. Conflict resolution: Tiers ensure predictable outcomes when multiple configurations target
the same resource. The configuration with the most critical deployment (lowest tier) takes priority.

Fixes projectsveltos#305
gianlucam76 pushed a commit to gianlucam76/addon-controller that referenced this issue May 14, 2024
ClusterProfile/Profile instances let deploy add-ons and applications
(Helm charts or Kubernetes resources) across a set of managed clusters.

Sometimes there might be a need to tweak deployments for specific clusters
(a subset of the original group) within that group.

Previously, creating a new ClusterProfile/Profile targeting a subset of clusters
with resources already managed by another profile resulted in conflicts.
Sveltos wouldn't allow deployment for those resources.

The concept of ```tier``` is introduced to manage deployment priority for
resources targeted by multiple configurations.

How it works:

1. Each ClusterProfile/Profile has a new property called __tier__.
2. This tier value controls the deployment order for resources targeting
the same cluster element (e.g., a Kubernetes object or Helm chart).
3. By default, the first configuration to reach the cluster "wins" and deploys the resource.
4. Tiers override this behavior. When conflicts occur, the configuration with the lowest tier
value takes precedence and deploys the resource. Higher tier values represent lower priority.
5. The default tier value is 100.

Benefits:

1. Finer control over resource deployment: Tiers allow you to fine-tune deployments within
your cluster, especially when multiple configurations manage the same resources.
2. Conflict resolution: Tiers ensure predictable outcomes when multiple configurations target
the same resource. The configuration with the most critical deployment (lowest tier) takes priority.

Fixes projectsveltos#305
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

1 participant