Argo CD v1.4 Released!

Alexander Matyushentsev
Argo Project
Published in
7 min readJan 18, 2020

The Argo Project is happy to announce the general availability of Argo CD 1.4, a declarative GitOps engine for Kubernetes! Before jumping into technical details we would like to inform about what is happening with the project in general and explain why v1.4 is different from previous Argo CD releases.

We’ve got a lot more users

Early adopters in the Argo Community are the best possible reviewers, testers and sources of feedback for new releases! They collectively try each release with many more types of applications and environments than is possible by the contributors. The community of early adopters pro-actively tested release candidates, reported issues and requested improvements. During recent months Argo CD adoption has increased dramatically. Many in the community are now using Argo CD to manage critical applications in production and new users are joining the community with higher expectations.

Users are using Argo CD at scale

We not only have more users but existing users are using Argo CD much more extensively. A great example is Intuit, the company behind Argo CD. The number of managed clusters, average cluster size, and deployment frequency have increased significantly. That created performance issues which were difficult to detect during testing.

The usage growth revealed gaps

Thanks to early community feedback and frequent iteration of release candidates, we managed to cover most of the important use cases for the 1.4 release. As more people adopt Argo CD we‘re realizing that these features are being used in ways that we never anticipated, and require some tuning and improvement to better support these new use cases. We’ve also discovered usability issues and some day-zero bugs. Lastly, we discovered that some features are not documented partially or documentation is missing altogether.

Argo CD and CNCF Flux joining forces

Last but not least Argoproj community is joining forces with the CNCF Flux community. As part of this effort, we want to take the best of both projects and move into a common GitOps engine library which will then be used by both the projects. Before it happens we want to make sure Argo CD core is stable as much as possible.

So what has changed?

We want to increase focus on stability and quality and making some improvements.

Dogfooding

The internal usage at Intuit helps a lot to catch issues in multiple areas of Argo CD. However, some Argo CD features that were proposed by the community are not used extensively by the developers, at Intuit. As you can imagine such features get less attention and that eventually affects quality.
We are doing extra effort to start using such features in our dogfood environments and promote them across the whole organization. For example, the Dev Argo CD instance is deployed using automated sync policy and the cluster state is corrected using self-healing feature. The Argo CD dogfood instance is leveraging recently released sync-windows feature.

Development and release process

We used to publish the Argo CD release candidate and then deploy it internally. It worked well and helped us to catch a lot of bugs with the community help. However recent releases were not as smooth as we expected. We had to create a bunch of release candidates, one after another and then followed the release with a bunch of patch releases. To address that issue we’ve made the following changes:

  • The master branch is continuously deployed to a dev instance that is used for testing and daily deployed to the dogfood clusters that our team is using. That means we will try to keep the master more stable.
  • No more ninja-style development and breaking the world with major refactoring. Implement more tests, features flags for big features and so on.
  • The first release candidate is created after it is deployed and verified internally on our production instances. The latest version is still available under argoproj/argo-cd:latest and we are planning to start publishing EAP images.

Prioritization

We’ve changed the way we prioritize new tasks as well as how we develop and test changes. We always prioritize bugs over everything else, but now we also want to prioritize usability enhancements and documentation. The main goal is to keep Argo CD stable and laser-focused on its main use-case: GitOps for Kubernetes. We want to make sure that existing features are actually useful and completely solving the use case before moving to the next existing feature.

Going forward before committing to adding brand new functionality we will evaluate how much effort is needed to develop the end-to-end solution and commit to implementing all the required pieces. Additionally, we want to leverage the fact that Argo CD is built on top of Kubernetes and CRDs that makes it very extensible. A lot of important features such as notifications, Github/Gitlab integrations could be implemented as optional side components. That provides a lot more flexibility since these components might be as opinionated as necessary and
not tied to the Argo CD release cycle. We’ve created the http://github.com/argoproj-labs/ Github organization to help increase visibility and adoption of such projects and encourage everyone to contribute.

The v1.4.0 release changes

The v1.4.0 is a stability release that brings multiple bug fixes, security and performance enhancements. We are also releasing multiple usability improvements that make existing features more accessible. The release has been verified in production already and is successfully driving hundreds of deployment every day at Intuit. This is the first step in the transition and we are going to make upcoming releases more and more stable.

Security

A number of security enhancements and features have been implemented.

  • Repository Credential Templates Management UI/CLI. Now you can use Argo CD CLI or UI to configure credentials template for multiple repositories!
  • X-Frame-Options header on serving static assets. The X-Frame-Options prevents third party sites to trick users into interacting with the application.
  • Tighten AppProject RBAC enforcement. We’ve improved the enforcement of access rules specified in the application project configuration.

Namespace isolation

With the namespace isolation feature, you no longer have to give full read-only cluster access to the Argo CD. Instead, you can give access only to selected namespaces within the cluster:

argocd cluster add <mycluster> -namespace <mynamespace1> -namespace <mynamespace2>

This feature is solving the following main use cases:

  • You don’t have full cluster access but still want to use Argo CD to manage some cluster namespaces.
  • Argo CD is used to manage a few namespaces of a large cluster. In this case, it makes sense to explicitly specify namespaces in cluster connection to reduce number Kubernetes API requests and improve performance.

Reconciliation performance

Argo CD no longer fork/exec kubectl to apply resource changes in the target cluster or convert the resource manifest to the required manifest version. This reduces CPU and Memory usage of large Argo CD instances.

Resources health-based hook status

The existing Argo CD resource hooks feature allows running custom logic during the syncing process. You can mark any Kubernetes resource as a hook and Argo CD assesses hook status if the resource is a Pod, Job or Argo Workflow. In the v1.4.0 release, Argo CD is going to leverage resource health assessment to get sync hook status. This allows using any custom CRD as a sync hook and leverage custom health check logic.

Manifest generation

  • Track helm charts by semantic version. You’ve been able to track charts hosted in Git repositories using branches to tags. This is now possible for Helm charts. You no longer need to choose the exact version, such as v1.4.0, instead, you can use a semantic version constraint such as v1.4.* and the latest version that matches will be installed.
  • Build environment variables. The feature allows the config management tool to get access to app details during manifest generation via environment variables.
  • Git Submodules. Argo CD is going to automatically fetch sub-modules if your repository has .gitmodules directory.

UI and CLI

  • Improved resource tree view. The Application details page got even prettier. The resource view was tuned to fit more resources into the screen, include more information about each resource and don’t lose usability at the same time.
  • New account management CLI command. The CLI allows to check which actions are allowed for your account: argocd account can-i sync applications '*' .

Maintenance tools

The team put more effort into building tools that help maintain Argo CD itself:

  • Bulk project editing. The argocd-util allows adding and removing permissions defined in multiple project roles using one command.
  • More Prometheus metrics. A set of additional metrics that contains useful information managed clusters is exposed by the application controller.

More documentation and tools are coming in patch releases.

Where Can I Get This?

For more details and installation instructions check v1.4 release notes.

Thanks To The Community!

Thanks a lot to everyone who contributed to this release! The community contributed an endless number of bug fixes, docs/usability improvements, and whole major features. The list of contributors includes almost 50 people not even counting ones who created bug reports and helped with testing. Thank you for your support!

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

--

--

Written by Alexander Matyushentsev

Co-founder and Chief Architect at Akuity | Argo Project Leader with 6-year tenure | ex-Intuit | Running the Enterprise Company for Argo — https://akuity.io

No responses yet

What are your thoughts?