Mirrors/flux2
1
0
Fork 0
mirror of synced 2026-03-14 15:36:56 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #5776 from fluxcd/rfcs-implemented

Browse Source 
Mark RFC 0010, 0011 and 0012 as implemented
This commit is contained in:
Matheus Pimenta
2026-03-13 20:38:50 +00:00
committed by GitHub
parent e9226713e8 64e18014c3
commit 3f9d5bdc3d
3 changed files with 16 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
rfcs/0010-multi-tenant-workload-identity/README.md
View File

@@ -1,15 +1,10 @@
# RFC-0010 Multi-Tenant Workload Identity # RFC-0010 Multi-Tenant Workload Identity
**Status:** implementable **Status:** implemented
<!--
Status represents the current state of the RFC.
Must be one of `provisional`, `implementable`, `implemented`, `deferred`, `rejected`, `withdrawn`, or `replaced`.
-->
**Creation date:** 2025-02-22 **Creation date:** 2025-02-22
**Last update:** 2025-04-29 **Last update:** 2026-03-13
## Summary ## 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 `HelmRepository` and `HelmChart`, as well as for SOPS decryption
in the `Kustomization` API and Azure Event Hubs in the in the `Kustomization` API and Azure Event Hubs in the
`Provider` API. `Provider` API.
* In Flux 2.7 object-level workload identity was introduced for all
<!-- the remaining APIs that support cloud providers, i.e. `Bucket`,
Major milestones in the lifecycle of the RFC such as: `GitRepository` and `ImageUpdateAutomation`, and also all the
- The first Flux release where an initial version of the RFC was available. remaining types for the `Provider` API, i.e. `azuredevops` and
- The version of Flux where the RFC graduated to general availability. `googlepubsub`. In addition, support for controller and
- The version of Flux where the RFC was retired or superseded. object-level workload identity was introduced for the
--> `Kustomization` and `HelmRelease` APIs for remote cluster
access.

16
rfcs/0011-opentelemetry-tracing/README.md
View File

@@ -1,15 +1,10 @@
# RFC-0011: OpenTelemetry Tracing # RFC-0011: OpenTelemetry Tracing
**Status:** provisional **Status:** implemented
<!--
Status represents the current state of the RFC.
Must be one of `provisional`, `implementable`, `implemented`, `deferred`, `rejected`, `withdrawn`, or `replaced`.
-->
**Creation date:** 2025-04-24 **Creation date:** 2025-04-24
**Last update:** 2025-08-13 **Last update:** 2026-03-13
## Summary ## 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. 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 ## Implementation History
<!-- * RFC implemented and generally available in Flux [v2.7.0](https://github.com/fluxcd/flux2/releases/tag/v2.7.0)
Major milestones in the lifecycle of the RFC such as:
- The first Flux release where an initial version of the RFC was available.
- The version of Flux where the RFC graduated to general availability.
- The version of Flux where the RFC was retired or superseded.
-->

11
rfcs/0012-external-artifact/README.md
View File

@@ -1,10 +1,10 @@
# RFC-0012 External Artifact # RFC-0012 External Artifact
**Status:** provisional **Status:** implemented
**Creation date:** 2025-04-08 **Creation date:** 2025-04-08
**Last update:** 2025-09-03 **Last update:** 2026-03-13
## Summary ## Summary
@@ -319,9 +319,4 @@ control the adoption of the `ExternalArtifact` feature in their clusters.
## Implementation History ## Implementation History
<!-- * RFC implemented and generally available in Flux [v2.7.0](https://github.com/fluxcd/flux2/releases/tag/v2.7.0)
Major milestones in the lifecycle of the RFC such as:
- The first Flux release where an initial version of the RFC was available.
- The version of Flux where the RFC graduated to general availability.
- The version of Flux where the RFC was retired or superseded.
-->