fluxcd
/
source-controller
mirror of https://github.com/fluxcd/source-controller.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
source-controller/docs/spec
History
Sunny 71d3870e0a
Avoid skipping reconciliation 
- Attempt short-circuiting clone only when the artifact is already in the
  storage.
- A successful no-op clone need not return an error, but a partial
  commit which contains only a hash + reference.
- On no-op clone, reconcileSource() populates the source build dir by
  copying the existing artifact and lets the reconciliation continue.
- Reconciliation is not skipped to allow other subreconcilers to operate
  on other parts of GitRepo object like include, ignore, etc, when
  attributes associated with them change but the remote repo has not
  changed.
- Add a function IsConcreteCommit() to differentiate between partial and
  concrete commit.
- Update and simplify go-git and libgit2 no-op clone tests.

Signed-off-by: Sunny <darkowlzz@protonmail.com>
 		2022-05-16 17:06:44 +05:30
..
v1alpha1 Updated docs to include GCP provider instructions 2021-10-14 14:26:33 -05:00
v1beta1 Fix make verify failures 2022-05-09 16:16:04 +01:00
v1beta2 Avoid skipping reconciliation 2022-05-16 17:06:44 +05:30
README.md Document Bucket API v1beta2 spec 2022-03-11 10:04:14 +01:00

README.md

Source Controller

The main goal is to define a set of Kubernetes objects that cluster admins and various automated operators can interact with to offload the sources (e.g. Git and Helm repositories) registration, authentication, verification and resource fetching to a dedicated controller.

Motivation

Each Flux and each Helm operator mirrors the Git repositories they are using, in the same way, using the same code. But other components might benefit from access to the source mirrors, and Flux and the Helm operator could work more in sympathy with Kubernetes by factoring it out.

If "sources" (usually git repos, but also Helm charts and potentially other things) existed in their own right as Kubernetes resources, components like Flux and Helm operator could use standard Kubernetes mechanisms to build on them; and, they could be managed independently of the components using them.

API Specification

Implementation

The controller implementation will watch for source objects in a cluster and act on them. The actions performed by the source controller could be:

  • validate source definitions
  • authenticate to sources and validate authenticity
  • detect source changes based on update policies (semver)
  • fetch resources on-demand and on-a-schedule
  • package the fetched resources into a well known format (tar.gz, yaml)
  • store the artifacts locally
  • make the artifacts addressable by their source identifier (sha, version, ts)
  • make the artifacts available in-cluster to interested 3rd parties
  • notify interested 3rd parties of source changes and availability (status conditions, events, hooks)

Impact to Flux

Having a dedicated controller that manages Git repositories defined with Kubernetes custom resources would:

  • simplify Flux configuration as fluxd could subscribe to Git sources in-cluster and pull the artifacts automatically without manual intervention from users to reconfigure and redeploy FLux
  • improve the installation experience as users will not have to patch fluxd's deployment to inject the HTTPS basic auth credentials, change the source URL or other Git and PGP related settings
  • enable fluxd to compose the desired state of a cluster from multiple sources by applying all artifacts present in flux namespace
  • enable fluxd to apply manifests coming from other sources than Git, e.g. S3 buckets
  • allow fluxd to run under a non-root user as it wouldn't need to shell out to ssh-keygen, git or pgp
  • enable fluxd to apply manifests coming from the most recent semver tag of a Git repository
  • allow user to pin the cluster desired state to a specific Git commit or Git tag

Impact to Helm Operator

Having a dedicated controller that manages Helm repositories and charts defined with Kubernetes custom resources would:

  • simplify the Helm Operator configuration as repository and chart definitions can be re-used across HelmRelease resources (see fluxcd/helm-operator#142)
  • improve the user experience as repositories requiring authentication will no longer require a repositories.yaml import / file mount
  • simplify the architecture of the Helm Operator as it allows the operator to work with a single source type (HelmChart) and way of preparing and executing installations and/or upgrades
  • allow the Helm Operator to run under a non-root user as it wouldn't need to shell out to git