Flux Roadmap

The following components are considered production ready:

The following GitOps Toolkit APIs are considered production ready:

  • source.toolkit.fluxcd.io/v1beta2
  • kustomize.toolkit.fluxcd.io/v1beta2
  • notification.toolkit.fluxcd.io/v1beta1
  • helm.toolkit.fluxcd.io/v2beta1
  • image.toolkit.fluxcd.io/v1beta1

The road to Flux v2 GA

In our planning discussions we have identified these possible areas of work, this list is subject to change while we gather feedback:

  • Stabilize the image automation APIs

    • Review the spec of ImageRepository, ImagePolicy and ImageUpdateAutomation
    • Promote the image automation APIs to v1beta1
  • Conformance testing

    • End-to-end testing for Flux bootstrap on AMD64 and ARM64 clusters
    • End-to-end testing for Flux image automation
  • Adopt Kubernetes server-side apply ( fluxcd/flux2#1889)

    • Replace kubectl usage in Flux CLI with server-side apply
    • Rewrite the kustomize-controller reconciler using server-side apply
  • Multi-tenancy lockdown

  • OCI Artifacts

    • RFC-0002 Flux OCI support for Helm
    • RFC Flux OCI support for Kubernetes manifests
  • API consolidation ( fluxcd/flux2#1601)

    • Adopt Kubernetes kstatus standard conditions
    • Standardize events and status conditions metadata
  • Documentation improvements

    • Consolidate the docs under fluxcd.io website
    • Gather feedback on the migration guides and address more use-cases
    • Cloud specific guides (AWS, Azure, Google Cloud)
    • Incident management and troubleshooting guides
    • Developer guides for contributing to and extending Flux

Security enhancements

Reach consensus on multi-tenancy enhancements and other security related proposals:

  • RFC-0001 Memorandum on the authorization model
  • RFC Access control for cross-namespace source references
  • RFC Flux Multi-Tenancy Security Profile
  • RFC Define Flux tenancy models

The road to Flux v1 feature parity

In our planning discussions we identified three areas of work:

  • Feature parity with Flux v1 in read-only mode
  • Feature parity with the image-update functionality in Flux v1
  • Feature parity with Helm Operator v1

Flux read-only feature parity

Flux v2 read-only is ready to try. See the Getting Started how-to, and the Migration guide.

This would be the first stepping stone: we want Flux v2 to be on-par with today’s Flux in read-only mode and FluxCloud notifications.

Goals

StateItem
✔️Offer a migration guide for those that are using Flux in read-only mode to synchronize plain manifests
✔️Offer a migration guide for those that are using Flux in read-only mode to synchronize Kustomize overlays
✔️Offer a dedicated component for forwarding events to external messaging platforms

Non-Goals

  • Migrate users that are using Flux to run custom scripts with flux.yaml
  • Automate the migration of flux.yaml kustomize users

Tasks

  • Design the events API
  • Implement events in source and kustomize controllers
  • Make the kustomize-controller apply/gc events on-par with Flux v1 apply events
  • Design the notifications and events filtering API
  • Implement a notification controller for Slack, MS Teams, Discord, Rocket
  • Implement Prometheus metrics in source and kustomize controllers
  • Review the git source and kustomize APIs
  • Support bash-style variable substitution as an alternative to flux.yaml envsubst/sed usage
  • Create a migration guide for flux.yaml kustomize users
  • Include support for SOPS

Flux image update feature parity

Image automation is available as a prerelease. See this guide for how to install and use it.

Goals

  • Offer components that can replace Flux v1 image update feature

Non-Goals

Tasks

Helm v3 feature parity

Helm support in Flux v2 is ready to try. See the Helm controller guide, and the Helm controller migration guide.

Goals

  • Offer a migration guide for those that are using Helm Operator with Helm v3 and charts from Helm and Git repositories

Non-Goals

  • Migrate users that are using Helm v2

Tasks

  • Implement a Helm controller for Helm v3 covering all the current release options
  • Discuss and design Helm releases based on source API:
    • Providing values from sources
    • Conditional remediation on failed Helm actions
    • Support for Helm charts from Git
  • Review the Helm release, chart and repository APIs
  • Implement events in Helm controller
  • Implement Prometheus metrics in Helm controller
  • Implement support for values from Secret and ConfigMap resources
  • Implement conditional remediation on (failed) Helm actions
  • Implement support for Helm charts from Git
  • Implement support for referring to an alternative chart values file
  • Stabilize API
  • Create a migration guide for Helm Operator users