v0.20.0

🚀 Features:

• ClusterProfile dependencies: a clusterProfile instance can now depend on other ClusterProfile instances. If ClusterProfile A depends on ClusterProfile B, for every matching cluster, add-ons and applications listed in ClusterProfile A won't be provisioned till all add-ons and applications listed in ClusterProfile B are provisioned.

🐛 Bug Fixed:

• When ClusterProfile is instructed to create resources in the management cluster, those resources were incorrectly considered stale and removed when new managed clusters started matching. This behaviour is now fixed by this commit.

v0.19.0

🚀 Features:
Introducing cluster sharding: when Sveltos is managing hundreds of clusters, it is advised to use cluster sharding to spread the load between multiple instances of Sveltos controllers. To enable horizontal scaling, add annotation on cluster sharding.projectsveltos.io/key.
The Sveltos shard-controller will detect new cluster shards and start new set of Sveltos controllers to handle all clusters in a given shard.

v0.18.2

🐛 Bug fixed:

• Fixes this bug causing configuration drift detection to not work in certain scenarios.

v0.18.1

🐛 Bug fixed:
Long running jobs are explained here
When a job is completed, if it is also present in the dirty list, it needs to be re-queued.
This new release picks a fix in that logic (job options were not copied in such scenarios).

v0.17.0

🚀 Features:
Rolling Update Strategy for ClusterProfile

A ClusterProfile might match more than one cluster. When adding or modifying a ClusterProfile, it is helpful to:

1. Incrementally add the new configuration to a few clusters at a time.
2. Validate health before declaring deployment successful.

This pull request introduces two new ClusterProfile Spec fields:

• MaxUpdate: Indicates the maximum number of clusters that can be updated concurrently.
  Value can be an absolute number (e.g., 5) or a percentage of desired pods (e.g., 10%). Defaults to 100%.

  • Example: When this field is set to 30%, when the list of add-ons/applications in ClusterProfile
    changes, only 30% of matching clusters will be updated in parallel. Only when updates in those clusters
    succeed will other matching clusters be updated.

• ValidateHealths: A slice of health validation expressed using the Lua language.

  • For instance, when deploying Helm charts, it is possible to instruct Sveltos to check deployment
    health (number of active replicas) before declaring the Helm chart deployment successful.

Benefits of a Rolling Update Strategy

A rolling update strategy allows you to update your clusters gradually, minimizing downtime and risk.
By updating a few clusters at a time, you can identify and resolve any issues before rolling out the
update to all of your clusters. Additionally, you can use the ValidateHealths field to ensure that
your clusters are healthy before declaring the update successful.

How to Use the Rolling Update Strategy

To use the rolling update strategy, simply set the MaxUpdate field in your ClusterProfile Spec to
the desired number of clusters to update concurrently.
You can also use the ValidateHealths field to specify any health validation checks that you want to perform.

For example, the following ClusterProfile Spec would update a maximum of 30% of matching clusters concurrently
and would check that the number of active replicas is greater than zero before declaring the update successful:

apiVersion: config.projectsveltos.io/v1alpha1
kind: ClusterProfile
metadata:
  name: kyverno
spec:
  clusterSelector: env=fv
  syncMode: Continuous
  maxUpdate: 30%
  helmCharts:
  - repositoryURL:    https://kyverno.github.io/kyverno/
    repositoryName:   kyverno
    chartName:        kyverno/kyverno
    chartVersion:     v3.0.1
    releaseName:      kyverno-latest
    releaseNamespace: kyverno
    helmChartAction:  Install
    values: |
      admissionController:
        replicas: 1
  validateHealths:
  - name: deployment-health
    featureID: Helm
    group: "apps"
    version: "v1"
    kind: "Deployment"
    namespace: kyverno
    script: |
      function evaluate()
        hs = {}
        hs.healthy = false
        hs.message = "available replicas not matching requested replicas"
        if obj.status ~= nil then
          if obj.status.availableReplicas ~= nil then
            if obj.status.availableReplicas == obj.spec.replicas then
              hs.healthy = true
            end
          end
        end
        return hs
      end

🐛 Bug Fixed:

Leftover ClusterConfigurations and ClusterSummaries after CAPI cluster deletion (more details projectsveltos/addon-controller#325)

v0.16.0

🚀 Features:

Projectsveltos can now manage also the management cluster.
Management cluster can be registered to be managed by Sveltos either as any other cluster or using sveltosctl register mgmt-cluster

v0.15.3

🚀 Features:

• Make management referenced resource name template: ClusterProfile can references resources in the management cluster which need to be fetched and whose values are then used to configure resources to be deployed in managed clusters. Those resources' namespaces/names can be expressed as template and reference Cluster namaspace/name

🐛 Bug Fixed:

• Reconcile ConfigMap/Secret when annotation change

v0.15.2

🐛 Bug Fixed:

• projectsveltos/addon-controller#308: if an Helm chart contains both CustomResourceDefinitions and instances of such resources, compliance validations won't work (helm dry run mode won't work). This limitation was added to Sveltos documentation and Sveltos code was fixed to make sure it works if no compliance validations are defined;
• Fixed an projectsveltos/event-manager#94 when EventBasedAddOn references multiple ConfigMaps or Secrets. Before this fix only the content of the last referenced ConfigMap/Secret was deployed by the auto-created ClusterProfile.

v0.15.1

🚀 Features:

• quickstart: addon-controller repo has now a Makefile target for trying out projectsveltos with a test cluster (it creates a management cluster with projectsveltos and workload cluster).

🐛 Bug Fixed:

• Changing ClusterProfile Reloader knob from true to false was incorrectly processed by sveltos-agent.

v0.15.0

🚀 Features:

• start rolling upgrade for Deployment, StatefulSet, DaemonSet instances when a mounted ConfigMap, Secret changes. ClusterProfile has a knob, Reloader. When this knob is set to true, any Deployment, StatefulSet, DaemonSet instance deployed by Sveltos because of such ClusterProfile will have a rolling upgrade triggered by Sveltos when any mounted ConfigMap/Secret changes.

🐛 Bug Fixed:

• some Sveltos components (classifiers, addon-compliance-controller) used to go in CrashLoopBackOff if clusterAPI was not installed in the management cluster;
• cluster classification based on Kubernetes version was not working properly on GKE clusters.