 Hello everyone, my name is Stefan Prodan, I'm a Flux maintainer, I'm working for WeWorks in the developer experience team. I'm very excited to share with you what happened with Flux since the last coupon. So the big news is that Flux has been promoted from sandbox incubation, but for those that are new to Flux, let me give you a little bit of background. We started Flux at WeWorks five years ago as an internal project that was meant to help us operate Kubernetes introduction. Like most Kubernetes users, we were using Qubectl to perform application deployments and infrastructure upgrades. We soon realized that these operations can be made in a collaborative manner by using Git as the desired state of our production system. So we needed a tool that would watch Git and reconcile the cluster state once changes are approved and merge in the repository. This is how the GitOps idea was born. Three years later, when GitOps became more popular, Flux joined the CNCF as a sandbox project. After joining CNCF, our community has grown exponentially, and you can see here the numbers in terms of contributors, contributions. The people that are maintaining Flux is no longer a WeWorks only project. Other companies have joined, and I want to thank them all for stepping up and helping with Flux. With more organizations adopting GitOps and cloud-native technologies and with Kubernetes evolving so fast, we've hit the limits of Flux initial design. We realized that if we want to accommodate more futures, help new contributors, extending Flux easily, we needed to break the monolith, and break the monolith into smaller independent components. So last year, we started designing a framework that we call the GitOps toolkit, and this framework is the foundation on which we are building Flux version 2, the next major iteration of Flux. So if Flux version 1 was a monolithical tool that could reconcile a cluster state from a single Git repo story, with version 2, we have a different aim. We want to provide the complete continuous delivery platform on top of Kubernetes. We support for common practices and the popular tools that are in this field, such as Customize, Helm, the new cluster EPI also offer observability inside your delivery pipelines. And we'll see how we got that. Here is a diagram that shows you how Flux can now manage multiple clusters, it can look at different sources and so on. Okay, let's talk about the GitOps toolkit. So what is the toolkit? The toolkit is a collection of Go libraries, APIs, and Kubernetes controllers. All these together can help you build declarative continuous delivery pipelines. And the toolkit is Kubernetes native. It's built with control runtime libraries. It can be configured using Kubernetes custom resources. It's composable. You can pick and choose components based on what you want to do. You can extend it easily. We have libraries that help you build your own controllers. And you can integrate those controllers back into the toolkit. It's secure. We try to bridge the gap between source control access and Kubernetes access in a way that you can validate the authenticity of a person that creates a commit. You can verify that that person has the right access to modify something on your production cluster. And then the toolkit can run those changes, those operations by impersonating a Kubernetes account which is restricted according to how the cluster admin defined that particular term. Also, the toolkit is event-driven. So you can subscribe to external events like a Git push or a Helm chart upload or a Docker push and define how these events should change the cluster state. Also, the toolkit has a component for you to define alerts. So events, what happens inside the cluster can be pushed outside the cluster using the alerting API. With this API, you can push alerts to Slack, Microsoft Teams, Discord, even write back to, let's say, GitHub commit status or GitLab. Some of the core features of Flux version 2 are multi-source. So you can describe your cluster state or your fleet of clusters from multiple Git repos, Helm repos, even buckets. You can define your cluster state in any kind of S3-compatible storage, for example, Minio. We have built-in secrets management. We integrate with Mozilla SOPs and Cloud KMS. Flux version 2 comes with multi-tenancy features where it impersonates users when it tries to reconcile something. You can also run Flux on a central cluster and control all your cluster fleets, all the clusters that are making your fleet without installing Flux on each cluster, and of course, observability. We issue events for everything that's happening. We have metrics, alerts, and we also offer Grafana dashboards for you to see what's happening with your continuous delivery pipelines. We've developed a new Flux CLI and also Terraform provider so we can have a GitOps first approach to bootstrapping clusters. The Flux CLI comes with a single command where, and with that command, you can create your Git repos, you can install Flux on the cluster and pair the two with deployment keys, team access, and so on. It works with a variety of Git providers over SSH directly with GitHub API or GitHub API and so on. Another update is that Flagger has joined the Flux family. What Flagger does is it decouples the deployment of an application from the release process. Flux does the deployment while Flagger can do the release through Canary with progressive traffic shifting, A-B testing, Blue-Green, Blue-Green with mirroring and so on. Flagger works with a variety of service mesh providers and ingress controllers. Finally, I'm going to ask you to join the Flux community. We have a Slack channel on CNCF and we use GitHub discussions for everything around Flux version, what futures are going to be shipped and so on. I've listed here some hot topics like we are now working on a Flux web user interface. If you want to participate in that, you have opinions of what the Flux UI should show users, what actions you could take through it and so on, please join GitHub and join our community. Thank you very much. Have a nice day.