Argo Rollouts celebrates “biggest release ever”, Events and Workflows throw in usability improvements

Argo Rollouts 1.1

While the last feature release of Argo flagship Argo CD is a couple of months old already, contributors have been busy moving projects Rollouts, Events and Workflows along, so that they’re now available in versions 1.1, 3.2, and 1.5 respectively.

Rollouts 1.1 is advertised as the progressive delivery project’s “biggest release ever” and comes packed with useful additions such as the capability to set up email, Slack or similar notifications for various events. It also saw the introduction of a dynamicStableScale flag that lets the tool scale down the stable ReplicaSet as traffic shifts to a canary instead of keeping the stable stack as was — which turned out to be a limiting factor for many teams. 

Users also gained the option to configure Rollouts to automatically abort a rollout if no progress was made in a set time — previously, this function was only an option in combination with an AnalysisRun. Since the behaviour on abort turned out to be slightly different between update strategies, there’s now a new field in the strategy section to define how long to keep a canary or preview scaled up should a rollout stop.

Teams looking to implement more meaningful experiments can now specify a weight in the Experiment template, which helps to use an Ingress or service mesh to split the traffic during an update for baseline vs canary comparisons. Istio users can also split their canary traffic against TLS routes, manage VirtualServices in different clusters, and update multiple VirtualServices in lockstep.

Starting with the 1.1 release, Rollouts’s dashboard can be run as a standalone Kubernetes service, CloudWatch has become an accepted metric provider, and the team has added an IP verification feature to make working with EKS or the AWS LoadBalancer Controller a bit more secure.

Workflows adds visualisation support

Workflow Engine Argo Workflows project promises 21 new features in version 3.2, which are mostly said to help with resource utilisation. There’s a new HTTP template which was developed together with the Kubeflow Pipeline team as a way of executing HTTP requests without starting a pod for each one. The feature is supported by a new Agent architecture that takes care of executing multiple HTTP templates in one pod.

Operation teams will also be interested to learn that they can now inline other templates in DAGs and steps, and set conditions for their retry strategies. Workflows’s UI was changed a bit as well and now sport a neat way to visualise Argo Dataflow pipelines, steps, and logfiles, for better orientation and a checkbox to mark all workflows on a list.

Events team cleans up project

Argo Events, the workflow automation framework of open-source project Argo, meanwhile bumped its version number up to 1.5. The update comes with the option to limit trigger rates to protect downstream services and some simplifications when creating workflows and Kubernetes resources. Events now also knows how to work with Bitbucket, use Pulsar for triggering, and handle multiple GitLab projects. 

Other than that the team has cleaned up the project a bit, removing an array of deprecated fields such as caCertPath, clientCertPath and clientKeyPath for tlsConfig in EventSources and Sensor, spec.nats.native.antiAffinity in EventBus, serverCertPath and serverKeyPath for webhook typed EventSource, and spec.replica in the EventSource object. The full list of deprecations and removals can be found in the Argo Events release notes.