diff --git a/rfcs/0010-multi-tenant-workload-identity/README.md b/rfcs/0010-multi-tenant-workload-identity/README.md index 9ed342d9..920e402e 100644 --- a/rfcs/0010-multi-tenant-workload-identity/README.md +++ b/rfcs/0010-multi-tenant-workload-identity/README.md @@ -1,15 +1,10 @@ # RFC-0010 Multi-Tenant Workload Identity -**Status:** implementable - - +**Status:** implemented **Creation date:** 2025-02-22 -**Last update:** 2025-04-29 +**Last update:** 2026-03-13 ## Summary @@ -1420,10 +1415,11 @@ options to call `gcp.NewTokenSource()` and feed this token source to the `HelmRepository` and `HelmChart`, as well as for SOPS decryption in the `Kustomization` API and Azure Event Hubs in the `Provider` API. - - +* In Flux 2.7 object-level workload identity was introduced for all + the remaining APIs that support cloud providers, i.e. `Bucket`, + `GitRepository` and `ImageUpdateAutomation`, and also all the + remaining types for the `Provider` API, i.e. `azuredevops` and + `googlepubsub`. In addition, support for controller and + object-level workload identity was introduced for the + `Kustomization` and `HelmRelease` APIs for remote cluster + access. diff --git a/rfcs/0011-opentelemetry-tracing/README.md b/rfcs/0011-opentelemetry-tracing/README.md index 768e05a4..3dd5e851 100644 --- a/rfcs/0011-opentelemetry-tracing/README.md +++ b/rfcs/0011-opentelemetry-tracing/README.md @@ -1,15 +1,10 @@ # RFC-0011: OpenTelemetry Tracing -**Status:** provisional - - +**Status:** implemented **Creation date:** 2025-04-24 -**Last update:** 2025-08-13 +**Last update:** 2026-03-13 ## Summary The aim is to be able to collect traces via OpenTelemetry (OTel) across all Flux related objects, such as HelmReleases, Kustomizations and among others. These may be sent towards a tracing provider where may be potentially stored and visualized. Flux does not have any responsibility on storing and visualizing those, it keeps being completely stateless. Thereby, being seamless for the user, the implementation is going to be part of the already existing `Alert` API Type. Therefore, `EventSources` is going to discriminate the events belonging to the specific sources, which are going to be looked up to and send them out towards the `Provider` set. In this way, it could facilitate the observability and monitoring of Flux related objects. @@ -210,9 +205,4 @@ This design ensures trace continuity even in challenging distributed environment ## Implementation History - +* RFC implemented and generally available in Flux [v2.7.0](https://github.com/fluxcd/flux2/releases/tag/v2.7.0) diff --git a/rfcs/0012-external-artifact/README.md b/rfcs/0012-external-artifact/README.md index 602c4918..c8d21bbf 100644 --- a/rfcs/0012-external-artifact/README.md +++ b/rfcs/0012-external-artifact/README.md @@ -1,10 +1,10 @@ # RFC-0012 External Artifact -**Status:** provisional +**Status:** implemented **Creation date:** 2025-04-08 -**Last update:** 2025-09-03 +**Last update:** 2026-03-13 ## Summary @@ -319,9 +319,4 @@ control the adoption of the `ExternalArtifact` feature in their clusters. ## Implementation History - +* RFC implemented and generally available in Flux [v2.7.0](https://github.com/fluxcd/flux2/releases/tag/v2.7.0)