RFC-0000 - Open Flux: Extending Source and Transformation Types ( aka. Generic Source Types )

[Skarlso]

Hello dear flux community.

We at OpenFlux would like to share a proposal/RFC with you and would like to officially start the RFC process.

I would like to keep the description of this discussion to a minimum so I'm sharing the draft RFC in a hackmd doc here:

https://hackmd.io/@skarlso/BkOvxwAeye

TL;DR we are suggesting to have a common Artifact custom resource type that any object could produce to be considered as a source object for flux to pick up. This would allow for community contributed source types.

We have a POC for such a community contributed source type, a http source with a corresponding controller, that showcases the modifications here: https-source-controller. This source controller is not a reimplementation of Flux source-controller, it is just a source type (like gitrepository or ocirepository).

Our modifications for this RFC are limited to kustomize and helm controller. There is no need to change any APIs and no need to change source-controller itself.

There is no need for dynamic watches, we provide that functionality through owner references and the contract for flux is kept with a Artifact in the status for an object. All objects need to implement the Source interface anyways.

Please have a read, and let's discuss. We'll take part in the coming Flux meetings on 6th of November 13:00 CET.

[Skarlso]

2024.11.06 Flux Community Meeting Notes

Clarifications:

• the http-source-controller is not a replacement for flux's source-controller, it's just a temporary POC to showcase the functionality we would like to implement. it's an example of a source provider.
• the openfluxcd organisation notes talk about modifying the API of GitRepository. That's a thought experiment. In reality, there is no need to modify these objects at all!
• there are no dynamic watches being introduced; we propose promoting the Artifact object located here Artifact v1beta2 to a K8s object. This is the object that will be monitored for modifications. It's basically an extra CRD that will be added.
• we propose not using that as a source object directly ( instead doing something like this:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
...
  sourceRef:
    kind: Http
    name: http-podinfo-kustomize
    apiVersion: openfluxcd.openfluxcd/v1alpha1
...

... because it improves, or rather, preserves user interaction of the system where Artifact is unknown to the user and they don't have to care about its existence, naming scheme, behaviour.

• versioning and breaking the gitops model: versioning will have to be taken care off by the producer of the artifact, flux only cares about digest+revision. If the provider can't produce a unique digest+revision for versioning schemes, they aren't a viable provider
• the proposed changes are exclusively in kustomize and helm controller. The only other change is promoting Artifact to a CRD.
• this whole thing is backwards compatible

Requested Amendments:

• we should add more examples of usage and more motivation sources
• we should research a bit about who or what or why this feature is requested or how it could benefit the flux community: To that end, we already have a bit of knowledge that this was discussed before, and the obvious motivation is that flux would be more open and would potentially attract more users. We will improve the example section with more concrete options.
• make it clear why the proposal is not just about adding a new Source Type called Artifact instead of the approach we are suggesting

Concerns:

• if the added source is arbitrary, that could potentially open up a can of hurt for the maintainers with people coming in with problems using custom source providers: this shouldn't be a problem because if there is an Artifact object, that's all the flux needs to care about. Other than that, Flux can say, we don't care or don't want to care about where it's coming from.

[Skarlso]

Updated the proposal and draft RFC with more details.

[siegenthalerroger]

From my quick review I get the feeling this is similar to the already existing HelmChart, just in a generic form. Is this correct in its understanding?

I love the idea of making it possible for new sources and/or deployers to be added without requiring explicit support from the other side.

[Skarlso]

From my quick review I get the feeling this is similar to the already existing HelmChart, just in a generic form. Is this correct in its understanding?

Absolutely, yes. HelmChart is an object that can generate an Artifact. In this regard, this would be a similar object, but ANY object could generate it and then be considered a Source.

I love the idea of making it possible for new sources and/or deployers to be added without requiring explicit support from the other side.

Thank you! That's fantastic to hear. If you have any scenarios, please don't hesitate to share! As my comment suggests we are going to extend things with more examples for motivation. :) :)

[Skarlso]

Please note that I'll be at KubeCon next week so I won't have time to update everything here. ( I'll try my best to add some more details and explanation to the RFC ). This discussion will be continued on the Flux Meeting at 20th of November.

Thank you for your patience.

[Skarlso]

Back from KubeCon. I will prepare for the meeting on the 20th!

[Skarlso]

Meeting Minutes from the discussion on the 20th of November

Design decision changes

Right now, the design dictates that any kind of source could become a source in the sourceRef. These changes would have some concerns listed below in the security section.

The design though would be significantly easier to do if it would introduce the Artifact as a 4th source instead of any other object.

This also would be simpler to implement.

Security ( or the appearance of it ) Concerns

The concerns are that opening the restriction that now is an enum for sourceRef to be of kind ANY would be a significant move even though underneath we would still only watch Artifact. This wouldn't be reflected in the API however because it would no longer be an enum but an open ended value.

This would trigger people ordering new security audits which are costly to understand what is being done to flux. Everything in the background is invisible to the user, so they wouldn't know what happens in the background and neither should they care.

This isn't a problem, however, would significantly increase adoption and implementation time.

This feature should be behind a feature flag and once it is implemented it should be an opt-in feature so security administrators could disabling dealing with third party objects and outside source providers.

Update implementation

The update should include extraction of artifact generation in the source controller. Further, an update to the Flux CLI including all operations that it does right now regarding debugging. It would further include code that could be used by third party controller to create and correct Artifacts such that flux would accept them. This includes hashing, taring and packaging, folder creation, and updating the Artifact status.

The third party would be responsible for validation and signing any artifacts and objects it generates.

Maintainability concerns

The maintainability concern is still the same. Flux maintainers will need to be able to redirect concerns that use Artifact objects to the third-party source provider that creates them.