GitOps Toolkit Roadmap and the road to Flux v2

We are very happy to announce that we finalised the plans for the GitOps Toolkit and thus the road to Flux v2. We are especially pleased as we got great feedback and contributions from a wide range of people.

As you all know Flux v1 is a monolithic do-it-all operator, and the GitOps Toolkit separates the functionality into specialized controllers. Flux v2 will be a curated configuration of the GitOps Toolkit which you can simply consume using the tk command. Limiting the use of features and/or adding extensions on top of Flux has never been this easy.

You can review the roadmap in greater detail here. The big blocks we want to land are:

  • Feature parity with Flux v1 in read-only mode (80% completed). Once we’re done we will be able to ask people to transition over.
  • Image update capabilities (design in progress). This constitutes the biggest block of work still.
  • Helm Operator v2 (50% done).

We will move Flux v1 into maintenance mode now (no new features will be added). Once above work items are done, we will still support Flux v1 for 6 months - this will be a transition period for everyone to update their deployments.

If you immediately want to get started and check things out, that’s great. You can find more information here:

We believe we are building something extraordinary here - we will need your help to do it! We want the GitOps Toolkit to be a set of components that fit the bill for all GitOps needs. One example for how the components are meant to be reusable is Flagger: the team is looking at using the Toolkit’s notification-controller.

Here are some ways how you can help:

Please talk to us if you have any questions or feedback.

2 Likes

Cross-posted from https://www.weave.works/blog/flux-v2-september-update

The Road to Flux v2 - September update

This is the first blog post in a series which accompanies the development of the GitOps Toolkit on the road to delivering Flux v2 and more. We want to highlight what has been happening in development in the past weeks, who has contributed and what you can look forward to. And if you are curious, how to try it out for yourself.

It has been three weeks since the Flux community announced their plans for Flux v2 that has been rebuilt from scratch and based on top of the new GitOps Toolkit. If you haven’t heard the news yet, here’s what we are planning on doing:

  1. The GitOps functionality in Flux and Helm Operator is now delivered by individual components, to enable and support far more use-cases and to simplify development.
  2. Everything is driven by Custom Resources for more control and better observability.
  3. We built the GitOps Toolkit from the ground up incorporating the most requested features:
  • Support for multiple source Git repositories
  • Operational insight through health checks, events and alerts
  • Multi-tenancy capabilities, such as applying each source repository with its own set of permissions

In April this year we started with early experimentation for building a proof-of-concept, which was first shown at the GitOps Days virtual event in May, followed by a request-for-comments period and roadmap discussions in June. Since then the Flux community has come a long way.

Our highlight in this episode: the road to Helm Operator v2

Since the announcement, the team has made great strides, especially in the area of Helm: around 90% of all the work related to building the “Helm Operator v2” is done. The Helm Controller now has support for values from Secret and ConfigMap resources, and support for strategies for handling different kinds of failure. Its API package is also available as an independent Go Module. Failure handling is a big one. It means that you can extensively configure how to automatically remediate an installation, test, or upgrade failure. This includes actions that should be performed to remediate (rollback or uninstall), the number of retries, and even if the release has failed and retries have expired, you can debug the issue more easily. In addition, it is possible to ignore test failures if necessary (as opposed to remediate after a failed “helm test”).

Also the API to support Helm releases, based on source API, has been discussed and designed. In particular, providing values from sources and support for Helm charts from Git. So what’s left for Helm Controller to be on par with today’s Helm Operator? Only implementing support for referring to an alternative chart values file. And of course lots of testing. Before we tell the world they can transition to Helm Operator v2, we need to hear from current users and integrate their feedback.

If you are using Helm Operator right now, it would be fantastic if you could test the Helm Controller: simply check out https://toolkit.fluxcd.io/guides/helmreleases/ and give us feedback on how the journey went for you (find contact info at the bottom of this blog post).

In other news

Here’s a recap of what happened in the project overall in the past three weeks:

  • Support for HelmChart artifacts built from GitRepository sources.
  • Various bug fixes, e.g. Notification Controller: fix to the Prometheus scraping endpoint.
  • We were approached by members of the Grafana Tanka project who decided to call their binary “tk” so we decided to go with “gotk” from now on.
  • In the future we will also be able to enable ARM support; one blocker for this is that Flux shelled out to the kustomize binary, which has been fixed now.
  • Mozilla SOPS decryption support is coming!

More projects starting to look at using go-git-providers: eksctl, libgitops, and through libgitops: ignite, crdconv, cluster-api-provider-existinginfra and wksctl.

Since Flux become a CNCF Sandbox project about a year ago, we formally started the process to review the project with the CNCF - the PR is worth a read if you are interested in where the project stands as a whole and what happened in the last year. The amount of care and contributions our large community of users and contributors has shown is somewhat mind-boggling. We are certainly very pleased with what we have achieved.

Development-wise the focus for the next few weeks is going to be:

  • Figuring out the final form of Flux v2
  • The next big milestone: Bringing the image automation on par with Flux v1
  • Increasing general test coverage

If you want to help us shape the future of any of these, please reach out - we would love to hear from you.

Special thanks to our contributors - here’s what they landed:

  • Martin H Berwanger improved the gotk install script and automated the upgrades of controller component dependencies in the Toollkit.
  • Sean Eagan contributed the conditional remediation on failed actions to the helm-controller.
  • Philip Laine implemented notifications for Github commits.
  • We also had many folks jump into conceptional work in our Github Discussions:
    • Shane Sveller is looking into non-curl-bash installation methods
    • Moshe Immerman had a look at the image update automation design
    • Sean Eagan has been working on various parts of the Helm controller planning. Calle Petterson, Jonas Arneberg and Steve Hipwell as well.
    • Daniel Morgan in SOPS support and Philip Laine in e2e testing, exposing image fields in kustomization resources and a possible Job controller.

There is still lots where you can help shape the future of the GitOps Toolkit. Some of the important discussions are:

We are looking forward to working with you.

Here is how you can get involved:

Cross-posted from https://www.weave.works/blog/the-road-to-flux-v2-october-update

The Road to Flux v2 - October update

The Flux community has set itself very ambitious goals for version 2 and as it’s a multi-month project we strive to inform you of what’s landed every month, including new possibilities that are available for integration and where you can get involved. Read last month’s update here.

Let’s recap what happened in September. There has been quite a lot.

Flux v1 is in maintenance mode

As already mentioned in the announcement of our Flux v2 and GitOps Toolkit plans, Flux v1 (and Helm Operator) are in maintenance mode and have been for a while. This means we are focusing all of our attention on v2 and we’ll only be working on Flux and Helm Operator v1 for critical updates and fixes. If you have important PRs that you want to land or if you are considering helping out with v1 maintenance, please talk to us. We want to make this transition work for everyone.

GitOps Toolkit about to reach a big milestone: 0.1.0

We have been working on the GitOps Toolkit for about six months and we have largely reached feature parity with Flux v1 (in read-only mode) and Helm Operator v1. The 0.1.0 milestone will mean that the APIs will be promoted to beta and that we will want more widespread testing and experimentation of Flux for those two sets of use-cases. Going forward, changes to the API will be accompanied by a conversion mechanism. With the v0.1 release the API becomes more stable but while in beta phase there are no guarantees about backwards compatibility between beta releases. We will also be working on migration paths and guides.

You can expect the release in the next couple of days and we would welcome any feedback you might have. Check out the “Get Started” guide (including others) on https://toolkit.fluxcd.io/.

This is a great achievement, so thanks a lot Bianca Cheng Costanzo, Daniel Holbach, Dinos Kousidis, Erik Hollensbe, Hidde Beydals, Ihor Dvoretskyi, Kevin McDermott, Leigh Capili, Lucas Käldström, Manuel Morejón, Martin H Berwanger, Michael Bridgen, Michael Cristina, Mike Beaumont, Philip Laine, Sara El-Zayat, Scott Rigby, Sean Eagan, Simon Howe, Stefan Prodan and Yiannis Triantafyllopoulos for your help thus far!

go-git-providers adding new maintainers and Gitlab support

Another Flux project that has seen new maintainers pick up the work is go-git-providers. Mike Beaumont, Simon Howe, Dinos Kousidis, Yiannis Triantafyllopoulos and Sara El-Zayat all work for Weaveworks and they stepped in to pick up where Lucas Käldström left off.

Dinos says:

“The project offers a common interface to run operations on different git providers. It defines an abstraction and mapping on repositories, organizations, and teams so that projects don’t have to combine provider specific ones (go-github, go-gitlab, etc.). We just released 0.0.3 which adds the gitlab provider alongside the github one that was added by Lucas. A BitBucket provider is also being discussed .”

In other news

The list of improvements and new features is long, so check out the links below to find out more:

The list goes on. We are particularly pleased with the thoughtfulness and tone of our growing community that is spec’ing out future features and integrations over in our Github Discussions section. There are many great things to come and we will showcase some of the work in our next episode.

We also created the /fluxcd/community repository. This is in response to a number of discussions which happened recently where we realised we want to better express our project-level governance and community docs - expect more discussion about this in future meetings, on Slack and elsewhere. If you would like to participate in this effort, talk to Daniel Holbach and Scott Rigby (or anyone else in the project really).

Get involved

If you like what you have read and would like to get involved, here’s how:

We are looking forward to working with you.

Cross-posted from https://www.weave.works/blog/the-road-to-flux-v2-november-update

The Road to Flux v2 - November update

Before we get started, what is GitOps?

If you are new to the community and GitOps, you might want to check out our GitOps manifesto or the official GitOps FAQ.

If you want to see the latest demo of GitOps Toolkit in action, check out this video:

The road to Flux v2

The Flux community has set itself very ambitious goals for version 2 and as it’s a multi-month project, we strive to inform you each month about what has already landed, new possibilities which are available for integration and where you can get involved. Read last month’s update here.

Let’s recap what happened in October - there have been many changes.

Flux v2 - what’s in a name?

In the past few weeks, we have found ourselves talking and explaining our plans for the future of the Flux project a lot more, and the received feedback was that the naming of the project was difficult to get used to, so here’s what we have decided to use in terms of naming:

  • Flux v2 now lives in the fluxcd/flux2 repository
  • the CLI was renamed to “flux”
  • the system namespace is called “flux-system”
  • And the website https://fluxcd.io will see consolidation in the next few days too.

The term GitOps Toolkit is a SDK for building Kubernetes controllers that can interact with Flux to extend its functionality.

This was the first decision made using the new Governance process (:arrow_down:more on this below).

Flux v1 is in maintenance mode

This means we

  • are focusing most of our attention on Flux v2
  • will only be working on Flux (and the Helm Operator v1) for critical updates and bug fixes

Flux is still being maintained and supported, it will just take a little bit longer to get around to addressing issues and PRs. Critical bug fixes have our priority. Read more about what this means.

(The same goes for Helm Operator v1.)

Flux v2 reaches 0.2.0

With 0.2.0 we are celebrating a big milestone. Two out of three of our big areas of workare done:

Regarding image updates, the design that replaces Flux v1’s image updates has been implemented. Here are instructions for installing and using it.

Since the last minor release we also added many more features. These are a few of our favourites:

  • Remote cluster targeting e.g. cluster-api support (we will add docs for this, but for now refer to the docs in the kustomize and helm controller repos)
  • Improvements to the handling of SemVer ranges (pre-releases are now excluded from e.g. 1.0.x ranges)
  • Added support for downloading dependency charts for Helm charts from GitRepository and Bucket sources
  • Picking the last version for ambiguous SemVer matches for GitRepository tag references, and charts from GitRepository sources (based on the timestamp metadata available in the source systems)

We also wrote a migration guide, so if you are curious and want to test Flux v2 in a Dev environment, please have a look at https://github.com/fluxcd/flux… and give us feedback. (A migration guide for Helm Operator will be published soon as well.)

The Flux project is growing up: our focus on governance and community

:mega: We’re happy to announce that we now have an official document to define the governance process for the Flux CNCF project and community.

:sparkling_heart: A lot of care was taken to ensure this reflected the spirit of the Flux community, the priority of users, and intent to broaden contributorship. We also connected with maintainers of other CNCF projects to learn what works well for them and what they may have done differently in terms of governance. With over 100 comments, the maintainers discussed and collaborated on this over a period of several weeks until finally reaching a happy consensus. If you want to see everything that went into this effort, it’s all discoverable in this pull request.

:clap: This is a major step forward for the Flux community: it will enable a broader contribution base as there is now a defined process for becoming more involved, and is a step toward CNCF project incubation and eventual graduation.

:construction: This comes with one notable change for Flux contributors: Developer Certificate of Origin (DCO) commit signoff will be required for all new code contributions in the fluxcd GitHub org repos. It’s easy to implement - for details, see our contributors guide.

:speech_balloon: Defining clear rules for governance and participation demonstrates how Flux has matured in the past four years since its inception: born out of a specific need to automate deployments at Weaveworks it quickly proved useful and moved on to be voted along with Helm as one of the few Cloud Native projects into the ADOPT category of the CNCF User Survey. With hundreds of contributors and an ever-growing number of organizations picking up Flux, it was time to agree on governance rules and further democratize the project.

Philip Laine joins notification-controller maintainers

notification-controller is the event forwarder and notification dispatcher for the GitOps Toolkit controllers (read the specification here).

For a few weeks now, Philip Laine has been helping out with the project and agreed to take on leadership for it too. Here’s a quick message from Philip:

Philip_Laine_.png

I am a DevOps engineer at a company called Xenit where I mostly work with Kubernetes and related tooling, where Flux is the obvious choice for CD. My first contribution to the notification controller was the GitHub provider. The provider allows the notification controller to update the status of a commit, when an event linked to that commit occurs. This will hopefully allow for deployment feedback that is closer to the code. I am currently looking at bringing to light use cases other than sending messages to Slack. These use cases could for example be triggering other actions inside the cluster when a specific event occurs. Getting involved has been very easy as community meetings and other communication is public. The community and maintainers have been great so far.

In our last Flux Dev meeting Philip also presented his work on the Flux v2 Terraform provider. Reach out to him if you have feedback or want to help. We’re super happy the Flux project is growing like this!

Upcoming events

The Flux community is already going out of their way to make sure people learn about what we’re building together. You might want to add these to your hearing/viewing list:

If you prefer live action, here are some upcoming events:

GitOps Days EMEA

GitOps Days EMEA 2020 is a 2-day online event on November 12-13, 2020 .

Day 1 will cover introductions to GitOps, the business value of GitOps, and use cases.

Day 2 we’ll nerd out and dive into more technical aspects, including workshops for:

  • Getting Started with GitOps
  • Flux v2 and the Future of Flux
  • Helm Operator and Helm Controller Migration

In other news

In recent weeks, we added Prometheus instrumentation for all the toolkit controllers. There is a new Grafana dashboard available that gives you an overview of the cluster reconciliation. The new dashboard displays the readiness status of each kustomization, helm release, git and helm repository along with stats about the duration of each reconciliation run. Here are the docs on how to install the monitoring stack: https://toolkit.fluxcd.io/guides/installation/#monitoring-with-prometheus-and-grafana

You can also check out the new [monitoring guide](https://toolkit.fluxcd.io/guides/monitoring/) which explains how to set up the monitoring stack. It covers the reconciliation metrics as well now.

Scott Rigby and Daniel Holbach joined as maintainers of the /website and /community repositories. In the upcoming weeks both will help out with the new website and start formalising some of the community plans, e.g. contributor happiness and communications. If you’d like to help out with any of these projects, have questions or concerns, please talk to us on Slack! :smiling_face_with_three_hearts:

If you like what you read and would like to get involved, here are a few good ways to do that:

We are looking forward to working with you.

Cross-posted from https://fluxcd.io/blog/2020/12/december-update/

December Update

2020-12-01 5 minute read

Before we get started, what is GitOps?

If you are new to the community and GitOps, you might want to check out the GitOps manifesto or the official GitOps FAQ.

The Road to Flux v2

The Flux community has set itself very ambitious goals for version 2 and as it’s a multi-month project, we strive to inform you each month about what has already landed, new possibilities which are available for integration and where you can get involved. Read last month’s update here.

Let’s recap what happened in November - there have been many changes.

Newest Flux v2 release: 0.4.0

The highlight is multi-tenancy support: you can now create tenants with the Flux CLI and restrict access to cluster resources with good old Kubernetes RBAC. Other notable changes: source operations for Git and Helm repositories, Helm charts and Buckets can now be suspended/resumed via Flux CLI or Git. This allows you to freeze the cluster reconciliation to the last fetched revision during an incident or on “No Release Fridays”. We’ve also fixed a couple of helm-controller issues and made available a CLI command to inspect the Helm charts status.

To get you started with setting up Flux and managing multi-tenant environments, an example repository and guide has been published on: https://github.com/fluxcd/flux2-multi-tenancy.

Guides for Helm users

If you have been using the Helm Operator in the past, you should be able to easily upgrade to the Helm Controller (Flux v2). Check out this guide and please give us feedback - we’d love to hear from you:

If you are interested in an example which describes how you can keep e.g. two clusters updated with minimal duplication, check out this repository - it uses Flux v2, Helm and Kustomize:

Aurel Canciu joins Flux v2 maintainers

Aurel Canciu has been putting quite a bit of work into Flux projects in the past weeks. We are very pleased to see his contributions across the project. Let’s hear a few words from Aurel himself:

As an avid promoter of the GitOps set of principles, I was very excited about the new Flux toolkit as a user, so naturally I decided to get involved and contribute to the best of my abilities and time availability. I am happy to now be part of an excellent team of maintainers and help move forward with this promising project.

Aurel Canciu

First milestone of fluxcd.io redesign landed

Ever since Flux moved into the CNCF Sandbox, we had a website for it which Luc Perkins created. For a while we have been thinking about how to best make use of the domain. We came up with a three-stage plan:

  1. Move to new them, point to Flux 2 resources
  2. Add a blog
  3. Subsume current docs and toolkit subdomains under fluxcd.io

Thanks to Hidde Beydals’s tireless work we were able to complete stage 1 and 2. Below is what it currently looks like:

If you want to help out with the next steps, please reach out.

Fantastic demo on Flux v2

We are very pleased Viktor Farcic from Codefresh took Flux v2 for a second spin and reviewed it in his demo. If you haven’t seen Flux v2 in action yet and want to know what the big deal is about check this out:

Flux v1 is in maintenance mode

This means we

  • are focusing most of our attention on Flux v2
  • will only be working on Flux (and the Helm Operator v1) for critical updates and bug fixes

Flux is still being maintained and supported, it will just take a little bit longer to get around to addressing issues and PRs. Critical bug fixes have our priority. Read more about what this means.

(The same goes for Helm Operator v1.)

The Flux Community team

The Flux community identified work that falls into the categories of contributor experience, advocacy and communications, community management as integral to its success long ago. While this has been an implicit focus of the team for a while, we want to build out the team, open it up and formalise processes.

If you are generally interested in helping out with this effort, let us know. For now we started some social media channels for Flux and want to inform the wider community about what’s happening.

We started a Flux LinkedIn group and Flux Twitter. We will put more effort into building out the Flux community. If you are keen to help in a non-coding fashion, we’re looking forward to hearing from you.

In other news

The Flux community is growing and we are in the middle of a quite a few big discussions:

If you like what you read and would like to get involved, here are a few good ways to do that:

  • Join our upcoming dev meeting on Dec 3
  • Talk to us in the #flux channel on CNCF Slack
  • Join the planning discussions
  • And if you are completely new to Flux v2, take a look at our Get Started guide and give us feedback
  • Social media: Follow Flux on Twitter, join the discussion in the Flux LinkedIn group.

We are looking forward to working with you.

Cross-posted from January 2021 Update | Flux

January 2021 Update

Before we get started, what is GitOps?

If you are new to the community and GitOps, you might want to check out the GitOps manifesto or the official GitOps FAQ.

The Road to Flux v2

The Flux community has set itself very ambitious goals for version 2 and as it’s a multi-month project, we strive to inform you each month about what has already landed, new possibilities which are available for integration and where you can get involved. Read last month’s update here.

Let’s recap what happened in December - there have been many changes.

Flagger moves under Flux CD

Flagger extends Flux functionality with progressive delivery strategies like Canary Releases, A/B Testing and Blue/Green and it was specifically designed for GitOps style delivery.

Since the inception of the GitOps Toolkit, it’s clear that fluxcd/ will become more of a family of GitOps related projects. The Flagger maintainers are looking forward to making use of the toolkit components and simplifying Flagger this way. Consolidating the code-bases and thinking in terms of a “Flux Family of Projects” and writing up the roadmap accordingly should benefit both communities as a whole.

The two Flagger maintainers (Stefan Prodan and Takeshi Yoneda) are very happy to see this happening. Thanks also to Weaveworks for agreeing to transfer Flagger and its copyright to fluxcd org (and thus, CNCF).

Review the upcoming roadmap for Flagger - it now includes GitOps Toolkit integration.

Please help us steer this project forward!

Thanks also to everyone who contributed to the latest two releases:

  • Flagger 1.6.0:
    • Add support for A/B testing using Gloo Edge HTTP headers based routing
  • Flagger 1.5.0:
    • Flagger can be installed on multi-arch Kubernetes clusters (Linux AMD64/ARM64/ARM).
    • The multi-arch image is available on GitHub Container Registry at ghcr.io/fluxcd/flagger.

Newest Flux v2 release: 0.5

:rocket: :gift: We’ve released Flux2 v0.5, this is the last release for 2020.

Besides bug fixes and performance improvements, it comes with many new features. The highlights are:

  • Alpha support for automated image updates to Git (thanks to Michael Bridgen - read more in the next paragraph)
  • Support for Azure DevOps and the Git v2 protocol (thanks to Philip Laine - more below)
  • Support for overriding container images in kustomize-controller (thanks to Somtochi Onyekwere)
  • “flux bootstrap” and install commands can now be used on Windows OS without WSL (thanks to Hidde Beydals)
  • flux can now be installed on Arch Linux using AUR packages ( flux-bin or flux-git for the latest release) (thanks to Aurel Canciu)

Automated Image Updates

Automated Image Updates Guide (alpha release)

Flux v2 now includes two controllers for automating image updates – one of the controllers is for scanning container image repositories, and the other updates and commits changes to YAML config, when there are new images to deploy.

These are the Flux v2 version of Flux’s automation, but work a little differently. The guide linked above explains how to set it up. Be aware that this is an alpha release for the image update automation controllers.

Azure DevOps repository support

Flux has not been able to support Azure DevOps repositories up until the 0.5 release. This was due to the git library go-git used by source-controller not supporting specific git capabilities required by Azure Devops. The same requirements do not exist in the other major git providers, which is why this was not caught during the initial development of source-controller.

This resulted in Flux v1 users who used Azure DevOps that were now not able to migrate to Flux v2. The initial attempt at a solution was to implement the missing capabilities in the existing library, which turned into its own epic. Instead the solution was to introduce a secondary git library libgit2 as it implements the required git capabilities. It turned out that libgit2 has its own limitations as it does not currently support shallow cloning, a feature that speeds up the git polling especially in very large git repositories. The compromise is to allow the user to choose which git library to use. The majority of users will be fine with the default original git library, while the Azure DevOps users will have to specify to use libgit2 in their GitRepository resources.

Follow the generic git server guide for further instructions in how to use Flux with Azure DevOps.

Upcoming events

In this session, Scott will go through the business value as well as the technical value for users + demo these benefits especially if you use Helm 3 with Flux 2.

In other news

The Flux community is growing and we are in the middle of a quite a few big discussions:

If you like what you read and would like to get involved, here are a few good ways to do that:

We are looking forward to working with you.