v0.23.0

🚀 Features:

• Allows Sveltos to get YAMLs/JSONs from flux sources

v0.22.0

🚀 Features:

• Allows to configure, per helm release, following helm options: skipCRDs, Wait, WaitForJobs, Atomic, DependencyUpdate, CreateNamespace;
• Health rules can be defined looking at objects of different GVKs all together. This allows for more complex health evaluations when Kubernetes resources need to be looked at together;
• deprecated add-on compliance validations.

🐛 Bug Fixes:

• Support for OCI registry;
• Avoid un-necessary helm upgrade (installed version vs expected version comparison fixed).

v0.21.1

🐛 Bug Fixes

• addon-controller not reacting to new cluster matching an existing profile bug
• addon-controller not cleaning up ClusterConfiguration for a deleted cluster which used to match a Profile bug
• resource deployed in drift-detection mode has spurious redeployment due to an issue detecting false configuration drift bug
• addon-controller logs reported an issue collecting ResourceSummary and ReloaderReport. That was a non issue as error was happening when ResourceSummary or the ReloaderSummary CRD were not deployed in a cluster bug

v0.21.0

🚀 Features:

• Introducing Profile CRD: similar to ClusterProfile, Profile has a cluster selector and a list of add-ons and applications to deploy in matching clusters. Unlike ClusterProfile, Profile is a namespaced resource and can only match clusters in its same namespace and reference resources in its same namespace. This makes Profile useful for managing multiple tenants in the management cluster, where each tenant has its own namespace.
• EventSource and Classifier now have the capability to analyze resources of different kinds simultaneously. This feature is enabled by the ResourceSelectors field, which allows you to select resources from various GroupVersionKinds and filter them based on various criteria, including: Namespace, Labels and Custom Lua functions for more sophisticated filtering. The optional AggregatedSelection field provides an additional layer of filtering for the resources selected using ResourceSelectors. This field accommodates a Lua function that further narrows down the subset of resources that have already been identified through ResourceSelectors. The function receives the array of resources selected by ResourceSelectors and processes it to eliminate or retain specific resources based on the specified criteria. If AggregatedSelection is not specified, all resources selected by ResourceSelectors will be considered. This feature enables more intricate filtering and selection operations on the resources, allowing for comprehensive analyses that consider all resources simultaneously. This capability is beneficial for more sophisticated tasks, such as identifying resources that are interconnected or share similar properties.
  further select a subset of the resources that have already been selected using the ResourceSelector field.
• Discord notification: on top of Slack and Webex, notifications can be sent to Discord channel as well

⚠️ Breaking Changes

• EventSource and Classifier CRDs have changed
• EventBasedAddOn CRD has been renamed to EventTrigger
• When using template, both Cluster and SveltosCluster can be referenced with keyword "Cluster"
• OpenAPI validations was removed (compliance validations can only be expressed using Lua)

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.18.0

🚀 Features:

• Sveltos can be configured to start agents (sveltos-agent and drift-detection-manager) in the management cluster. Default behaviour is to start those agents in each managed cluster
• SveltosCluster has new field KubeconfigName which allows overriding the default sveltos convention which expected a valid kubeconfig to be hosted in a secret with the pattern ${sveltosClusterName}-sveltos-kubeconfig.

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 release 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 #325)