Is your feature request related to a problem ?

To reflect breaking changes in a chart you would start to increase the major semver number. So all chart version are a 0.x at the moment thats a problem. PR #61 is a good example.

Describe the solution you'd like.

I would like to release a version 1.x of each chart. So we can make it obvios, if we release a chart with breaking changes and increase the major numbers.

Describe alternatives you've considered.

Maybe we collect some features we want to provide in the first 1.x releases. (IMHO we use this charts already, so I would just give it a 1.x)

Additional context.

No response

Is your feature request related to a problem ?

Please update the Flux chart to appVersion v0.33.0

Describe the solution you'd like.

Updated to v0.33.0: https://github.com/fluxcd/flux2/releases/tag/v0.33.0

Describe alternatives you've considered.

NONE

Additional context.

No response

When the chart is sufficiently mature it must be published on artifacthub.io

Please update the Flux chart to v0.32.0

Highlights

Flux v0.32.0 comes with support for distributing Kubernetes manifests, Kustomize overlays and Terraform code as OCI artifacts.
For more information please see the Flux OCI documentation.

New features

• New Flux CLI commands flux push|pull|tag artifact for publishing OCI Artifacts to container registries.
• New source type OCIRepository for fetching OCI artifacts from container registries.
• Resolve Helm dependencies from OCI for charts defined in Git.

Components changelog

• source-controller v0.26.0 v0.26.1
• kustomize-controller v0.27.0
• notification-controller v0.25.0 v0.25.1
• image-reflector-controller v0.20.0
• image-automation-controller v0.24.1

Is your feature request related to a problem ?

Notification controller receivers allow forges like github or gitlab to send events when the repository state changes, allowing to reduce latency without unreasonable polling frequencies.

For the notification controller to be reachable, most clusters will require an ingress object in addition to the service (especially since it is hardcoded to ClusterIP).

Describe the solution you'd like.

I believe it will be great if the flux2 helm chart allowed to configure an ingress object from values.yaml. This object would be disabled by default to prevent accidental exposure of the notification controller.

Describe alternatives you've considered.

Adding the ingress object separately from the helm chart is something possible, but causes friction as in order to locate the service from the ingress object, you need to know labels and release names that are defined inside the chart. Having to duplicate these to a separate point makes easy to accidentally misconfigure the ingress object.

Additional context.

If this is a feature you want to add, please LMK. I have some experience working with charts and I'm open to implement it here.

In our environments, we do not use the default cluster domain of cluster.local -- this either needs to be a variable, or allow resolv search domains to be used by dropping the domain.

Given that these charts are community maintained, what's the expected time frame from the moment a Flux release is published to the moment flux2 and flux2-sync charts are updated and released?

Should we add a notice to the main readme and to each chart readme that delays are expected and there are no guarantees about keeping up with upstream?

Describe the bug a clear and concise description of what the bug is.

We use just the kustomize-controller and source-controller, and we have disabled notifications controller.
however, event-addr has a default value which is rendered

Hence, the logs are populated with the error

POST http://notification-controller/ giving up after 5 attempt(s): Post \"http://notification-controller/\": dial tcp: lookup notification-controller on 169.254.20.10:53: no such host

As a fix, we can set event-addr to empty string when notification-controller is set as false

What's your helm version?

3.8.2

What's your kubectl version?

1.24.1

What's the chart version?

1.4.0

What happened?

Kustomize controller tried to make post call to notification controller even though notification controller did not exist.

What you expected to happen?

kustomize controller should not try making the API call to notification controller when notification controller does not exist.

How to reproduce it?

Disable notification controller and run with just source and kustomize controller.

Enter the changed values of values.yaml?

set notification controller as false

Enter the command that you execute and failing/misfunctioning.

kubectl logs of kustomize controller.

Anything else we need to know?

No response

Is your feature request related to a problem ? Yes

I'd like to migrate from using flux install --export to using the flux2 helm chart. However our usage of flux currently takes advantage of some of the extra flags that flux install supports. Specifically we do not download containers from the internet, so the container images need to come from an internal repository and need to use an image-pull-secret (which is already available in the k8s cluster).

it would stand to reason that there is a need for the optional flux arguments, i.e. being able to set these values will be needed by other users who would like to migrate.

The flux 0.24.1 version currently supports

Describe the solution you'd like.

At a minimum I'd like a new value variable defined for the image-pull-secret setting which would apply to all controllers.

Although for my use case it would be sufficient to add a stanza to the sa-* (service account) templates, the flux install manifests add the stanza to the deployment specs, so probably that would be the way to do it so it doesn't assume use of serviceaccount: create: true.

A more general solution would cover the other empty cases in the table above: cluster-domain and network-policy

Describe alternatives you've considered.

• Do not migrate from our current solution using flux install --export.
• Download the chart source from this repo, then manually modify the helm charts to add the image pull secret variable and add the stanza to use it. This would require redoing on every upgrade.

Additional context.

Relevant abridged snippet of a manifest generated by flux install --export --image-pull-secret mysecret --registry myartifactory.mycompany.net/fluxcd:

apiVersion: apps/v1
kind: Deployment
metadata:
    name: helm-controller
    namespace: flux-system
spec:
    template:
        spec:
            containers:
                - args:
                    - --watch-all-namespaces=true
                  image: myartifactory.mycompany.net/fluxcd/helm-controller:v0.14.1
            imagePullSecrets:
                - name: mysecret

Is your feature request related to a problem ?

Sometimes, accessory to the installation there may be manifest to be installed (for example a SecretProviderClass).

Describe the solution you'd like.

It would be nice to be able to do this directly via the Chart using the approach that ArgoCD also uses.

Ref: https://github.com/argoproj/argo-helm/blob/cf57a71a154a1a8a19f5f9d3980d60eb3efd80c8/charts/argo-cd/values.yaml#L62-L87

Describe alternatives you've considered.

I don't think there are alternatives

Additional context.

No response

@dwerder has been contributing significant features to helm-charts over the past few weeks He has also been responsive and reactive to opened issues and fixes.

This issue proposes adding @dwerder as a helm-charts maintainer. Existing maintainers should indicate votes in the comments.

/cc @stefanprodan @hiddeco @pierluigilenoci

Describe the bug a clear and concise description of what the bug is.

Please include a secret.data: {} example as I cannot get a secret to work. This is due to the fact that It doesn't appear that data: {} accepts a multi line string which is needed to accept an ssh private key, I don't believe json accepts multiline values. can this be changed to be more multi line string friendly?

What's your helm version?

latest stable

What's your kubectl version?

latest stable

What's the chart version?

latest stable

What happened?

json only accepts string

What you expected to happen?

I expect to be able to paste an ssh key in as a string in the value and have it work

How to reproduce it?

secret:
create: true
data: {"foo": "SSH KEY"}

Enter the changed values of values.yaml?

secret:
create: true
data: {} <-- this is the problem value

Enter the command that you execute and failing/misfunctioning.

i'm running via terraform via a helm_release resource but this is the same as the helm install command listed here

Anything else we need to know?

no

Describe the bug a clear and concise description of what the bug is.

When you have PSPs or anything equivalent set up in the cluster which denies Pods from running as root, the Installation of the helm chart will fail, because of the failing Pre-install hook (fux-cli seems to be running as root by default). There is currently also no workaround for this (ok, one very dirty of giving the default service account those privileged rights), because postrender scripts are not evaluated for helm hooks because of a bug in helm (helm/helm#7891).

What's your helm version?

v3.7.0

What's your kubectl version?

v1.22.2

What's the chart version?

flux2-0.8.6

What happened?

Installation fails

What you expected to happen?

Installation succeeds

How to reproduce it?

1. Setup PSPs wich require runAsNonRoot
2. Install Chart

Enter the changed values of values.yaml?

NONE

Enter the command that you execute and failing/misfunctioning.

helm install flux2 fluxcd-community/flux2 -n flux-system

Anything else we need to know?

There should be some easy solutions for this like

• running pod as non-root (runAsUser: 10000 should be sufficiant because this pod only executes the one command, which is possible with every uid) like so steveizzle@7b5c0c3
• or the possibility of having a dedicated serviceAccount for the job (which then can be bound to a role with a special psp) like so steveizzle@be2a34b

i could also help implementing it

Is your feature request related to a problem ?

https://github.com/haarchri/helm-charts-1/runs/4497426608?check_suite_focus=true

Describe the solution you'd like.

disable release step in/for forks

Describe alternatives you've considered.

no

Additional context.

No response

Is your feature request related to a problem ?

If needing to use an Azure service principal to decrypt sops secrets, there doesn't currently exist an option to configure one via the helm values.

Describe the solution you'd like.

Following a similar approach used in the flux v1 helm chart, would like to propose these values exposed and the kustomize controller template updated (see https://github.com/MxNxPx/helm-charts/tree/kustomize-envFrom).

Updated these files:

• https://github.com/MxNxPx/helm-charts/blob/kustomize-envFrom/charts/flux2/README.md
• https://github.com/MxNxPx/helm-charts/blob/kustomize-envFrom/charts/flux2/values.yaml
• https://github.com/MxNxPx/helm-charts/blob/kustomize-envFrom/charts/flux2/Chart.yaml
• https://github.com/MxNxPx/helm-charts/blob/kustomize-envFrom/charts/flux2/templates/kustomize-controller.yaml

Describe alternatives you've considered.

NONE

Additional context.

The following branch should be ready for submitting a PR if sign off is given: https://github.com/MxNxPx/helm-charts/tree/kustomize-envFrom

Flux images should come from ghcr.io:

$ flux install --export | grep ghcr
        image: ghcr.io/fluxcd/helm-controller:v0.12.1
        image: ghcr.io/fluxcd/kustomize-controller:v0.16.0
        image: ghcr.io/fluxcd/notification-controller:v0.18.1
        image: ghcr.io/fluxcd/source-controller:v0.17.1

Describe the bug a clear and concise description of what the bug is.

We use the spec targetNamespace for some of our helm releases to install them in a particular namespace.
but the release shows up when we query kube-infrastructure namespace.

ex- helm list -n kube-infrastructure should list only the releases installed under namespace kube-infrastructure. But we get some that are installed in different namespaces.

What's your helm version?

version.BuildInfo{Version:"v3.9.0", GitCommit:"7ceeda6c585217a19a1131663d8cd1f7d641b2a7", GitTreeState:"clean", GoVersion:"go1.18.2"}

What's your kubectl version?

Client Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.2", GitCommit:"f66044f4361b9f1f96f0053dd46cb7dce5e990a8", GitTreeState:"clean", BuildDate:"2022-06-15T14:14:10Z", GoVersion:"go1.18.3", Compiler:"gc", Platform:"darwin/amd64"}

What's the chart version?

flux2-0.20.0

What happened?

helm list -n kube-infrastructure list helmreleases that are not installed in kube-infrastructure namespace.

What you expected to happen?

helm list -n kube-infrastructure should list only helmreleases that are installed in kube-infrastructure namespace.

How to reproduce it?

No response

Enter the changed values of values.yaml?

No response

Enter the command that you execute and failing/misfunctioning.

helm list -n kube-infrastructure

Anything else we need to know?

No response

Is your feature request related to a problem ?

Support passing in extraEnv variables to helmController, notificationController, kustomizationController, sourceController

Describe the solution you'd like.

Support passing in extraEnv variables to helmController, notificationController, kustomizationController, sourceController

Describe alternatives you've considered.

.

Additional context.

No response

Describe the bug a clear and concise description of what the bug is.

since #55 we have issues with kustomization / kustomizationlist

values.yaml:

            values:
              gitRepository:
                spec:
                  url: https://github.com/xxx.git
                  ref:
                    branch: master
              kustomizationlist:
                - spec:
                    interval: 5m
                    path: ./flux2-kustomize/test
                    prune: true
                    timeout: 5m
                - spec:
                    dependsOn:
                      - path: ./flux2-kustomize/test
                    interval: 5m
                    path: ./flux2-kustomize/configuration
                    prune: true
                    timeout: 5m

results in: 3 kustomizations

flux-system   xxx                                 False   Cluster/xxx namespace not specified, error: the server could not find the requested resource (patch clusters.xxx.io xxx)...   41m

flux-system   xxx-flux2-kustomize-configuration   True    Applied revision: feature/flux2/a98f8afc6581d421c1e8e8b063a0191d4e7075d1                                                                                                                       41m

flux-system   xxx-flux2-kustomize-crossplane      True    Applied revision: feature/flux2/a98f8afc6581d421c1e8e8b063a0191d4e7075d1                                                                                                                       41m

side note:
we have also issues if dependsOn Path and Release Name is more then 63 characters long: https://github.com/fluxcd-community/helm-charts/blob/main/charts/flux2-sync/templates/kustomization.yaml#L75

What's your helm version?

version.BuildInfo{Version:"v3.7.1", GitCommit:"1d11fcb5d3f3bf00dbe6fe31b8412839a96b3dc4", GitTreeState:"clean", GoVersion:"go1.17.2"}

What's your kubectl version?

Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.2", GitCommit:"8b5a19147530eaac9476b0ab82980b4088bbc1b2", GitTreeState:"clean", BuildDate:"2021-09-15T21:31:32Z", GoVersion:"go1.16.8", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"21+", GitVersion:"v1.21.2-eks-06eac09", GitCommit:"5f6d83fe4cb7febb5f4f4e39b3b2b64ebbbe3e97", GitTreeState:"clean", BuildDate:"2021-09-13T14:20:15Z", GoVersion:"go1.16.5", Compiler:"gc", Platform:"linux/amd64"}

What's the chart version?

0.3.6

What happened?

No response

What you expected to happen?

No response

How to reproduce it?

No response

Enter the changed values of values.yaml?

No response

Enter the command that you execute and failing/misfunctioning.

kubectl

Anything else we need to know?

No response

Great thank you. Now we can add OCI as an alternative install method to the main readme and all chart readmes.

Originally posted by @stefanprodan in #94 (comment)

Describe the bug a clear and concise description of what the bug is.

See this issue: fluxcd/helm-controller#542

The problem is that the CRD is not up2date:
See
https://github.com/fluxcd-community/helm-charts/blame/main/charts/flux2/templates/helm-controller.crds.yaml#L723
vs
https://github.com/fluxcd/helm-controller/blame/main/config/crd/bases/helm.toolkit.fluxcd.io_helmreleases.yaml#L708

What's your helm version?

v3.9.4

What's your kubectl version?

v3.9.4

What's the chart version?

1.6.0

What happened?

No response

What you expected to happen?

No response

How to reproduce it?

No response

Enter the changed values of values.yaml?

No response

Enter the command that you execute and failing/misfunctioning.

N/A

Anything else we need to know?

No response

Describe the bug a clear and concise description of what the bug is.

lables for most of the deployments not working

What's your helm version?

version.BuildInfo{Version:"v3.6.0", GitCommit:"7f2df6467771a75f5646b7f12afb408590ed1755", GitTreeState:"dirty", GoVersion:"go1.16.4"}

What's your kubectl version?

Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.1", GitCommit:"5e58841cce77d4bc13713ad2b91fa0d961e69192", GitTreeState:"clean", BuildDate:"2021-05-12T14:11:29Z", GoVersion:"go1.16.3", Compiler:"gc", Platform:"darwin/arm64"} Server Version: version.Info{Major:"1", Minor:"21+", GitVersion:"v1.21.2-eks-0389ca3", GitCommit:"8a4e27b9d88142bbdd21b997b532eb6d493df6d2", GitTreeState:"clean", BuildDate:"2021-07-31T01:34:46Z", GoVersion:"go1.16.5", Compiler:"gc", Platform:"linux/amd64"}

What's the chart version?

0.4.0

What happened?

    message: 'create failed: failed to install release: YAML parse error on flux2/templates/kustomize-controller.yaml:
      error converting YAML to JSON: yaml: line 20: mapping values are not allowed

What you expected to happen?

working labels

How to reproduce it?

      sourcecontroller:
        labels:
          crossplane.io/claim-name: test
          crossplane.io/claim-namespace: test
          crossplane.io/composite: test

Enter the changed values of values.yaml?

      sourcecontroller:
        labels:
          crossplane.io/claim-name: test
          crossplane.io/claim-namespace: test
          crossplane.io/composite: test

Enter the command that you execute and failing/misfunctioning.

crossplane composition rollout

Anything else we need to know?

No response

Is your feature request related to a problem ?

I am trying to wrap my head around flux and how it works and then once I am there work out what the best installation method is for our situation. Right now this helm chart and the terraform method are both appealing to me because we have an extensive Terraform base.

Most howto's and instructions on how to setup a clusters take you to the CLI, which is something I won't be able to do: example:

https://github.com/fluxcd/flux2-kustomize-helm-example#bootstrap-staging-and-production

flux bootstrap github \
    --context=staging \
    --owner=${GITHUB_USER} \
    --repository=${GITHUB_REPO} \
    --branch=main \
    --personal \
    --path=clusters/staging

Is there a way in this chart to complete this setup?

Describe the solution you'd like.

Some sort of secret that one the chart is applied I can create that creates this config or better yet a secret in the chart.

Describe alternatives you've considered.

so far apart from the CLI method, I have only found this method in the terraform provider.

https://registry.terraform.io/providers/fluxcd/flux/latest/docs/guides/github

https://registry.terraform.io/providers/fluxcd/flux/latest/docs/data-sources/sync

Additional context.

Ohhhhhhhhhhhhhhh, it just dawned on me..... Is that what the flux2-sync chart is for in this repo? Please confirm. Maybe some doco and examples should be created in this repo and you can use my feature request here as a corner stone for an example.

Is your feature request related to a problem ?

With latest release I get an error in pre-hook that only 1.19 is supported.
Can you support 1.18?
is there some feature that is not supported in 1.18? if yes, could you do some if logic to support both?

Also, please add this kind of information in the main readme.

Thanks.

Describe the solution you'd like.

Support 1.18 release as well.

Describe alternatives you've considered.

We think to migrate newer version, but until that, we would be blocked to use this chart until that if you cannot support 1.18.

Additional context.

No response

Is your feature request related to a problem ?

no

Describe the solution you'd like.

add in ci

make generate
make helmdocs
make check-diff

so we can check that generate and helmdocs was executed in the commit and no file is changed

Describe alternatives you've considered.

no

Additional context.

No response

Describe the bug a clear and concise description of what the bug is.

While using flux-sync helm chart, to deploy the flux changes.
I either use helm template to get the k8s manifests and do k apply -Rf folder-name-of-generated-manifests or do a helm release. In both the cases, I get the error:

esource mapping not found for name: "flux-capacitor" namespace: "flux2" from "STDIN": no matches for kind "GitRepository" in version "source.toolkit.fluxcd.io/v1beta2"
ensure CRDs are installed first
resource mapping not found for name: "flux-capacitor" namespace: "flux2" from "STDIN": no matches for kind "Kustomization" in version "kustomize.toolkit.fluxcd.io/v1beta2"
ensure CRDs are installed first

However, when I re-run kubectl apply it works. So, I suspect that the order in which the crds and crd instances are tried to create or incorrect.

To fix this, we could have a helm hook that ensures that the crds are installed first before the crd instances are created.

Note: I would have raised a fix for this myself but I couldn't find any .crds.yaml file for kustomization or gitrepository crds.

What's your helm version?

3.8.2

What's your kubectl version?

1.24.1

What's the chart version?

0.4.0

What happened?

1. Use flux2-sync
2. Use helm template to create k8s manifests yaml
3. Use kubectl apply to create the resources

Getting the error:

resource mapping not found for name: "flux-capacitor" namespace: "flux2" from "STDIN": no matches for kind "GitRepository" in version "source.toolkit.fluxcd.io/v1beta2"
ensure CRDs are installed first
resource mapping not found for name: "flux-capacitor" namespace: "flux2" from "STDIN": no matches for kind "Kustomization" in version "kustomize.toolkit.fluxcd.io/v1beta2"
ensure CRDs are installed first

What you expected to happen?

The CRDs should be installed before the crd instance are tried to be created.

How to reproduce it?

See the section "what happened?" it has steps to reproduce.

Enter the changed values of values.yaml?

flux2:
enabled: false
flux2-sync:
gitRepository:
spec:
url: "https://github.com/suryapandian/podinfo"
spec:
targetNamespace: sample

Enter the command that you execute and failing/misfunctioning.

helm upgrade --install flux2 ./charts/flux2

or

 helm template flux-templates ./charts/flux2  \
      --namespace sample \
      --values tests/flux2/values.yaml \
      | kubectl apply -f -

Anything else we need to know?

No response

Is your feature request related to a problem ?

no

Describe the solution you'd like.

generate imageTags for all controller:
https://github.com/fluxcd-community/helm-charts/blob/main/charts/flux2/values.yaml#L18
https://github.com/fluxcd-community/helm-charts/blob/main/charts/flux2/values.yaml#L28
https://github.com/fluxcd-community/helm-charts/blob/main/charts/flux2/values.yaml#L68
https://github.com/fluxcd-community/helm-charts/blob/main/charts/flux2/values.yaml#L90
https://github.com/fluxcd-community/helm-charts/blob/main/charts/flux2/values.yaml#L112
https://github.com/fluxcd-community/helm-charts/blob/main/charts/flux2/values.yaml#L153
https://github.com/fluxcd-community/helm-charts/blob/main/charts/flux2/values.yaml#L175

since #45 we have a generator in-place to fetch all crds from flux2 upstream - add function to generate imageTags out of URLs in kustomization.yaml https://github.com/fluxcd/flux2/blob/main/manifests/crds/kustomization.yaml#L4-L9

eg. set imageTags in values.yaml with yq

for FILE in `cat .work/flux2/manifests/crds/kustomization.yaml | grep -Eo "(http|https)://[a-zA-Z0-9./?=_%:-]*"` 
do 
tag=$(cat version from ${FILE}) yq e -i '.controller.tag = env(tag)' ./charts/flux2/values.yaml
done

yq expression for each controller:

.cli. tag
.helmcontroller.tag
.imageautomationcontroller.tag
.imagereflectorcontroller.tag
.kustomizecontroller.tag
.notificationcontroller.tag
.sourcecontroller.tag

Describe alternatives you've considered.

no

Additional context.

No response

Check if the chart comply to all best practices:
https://helm.sh/docs/chart_best_practices/conventions/

Please update the Flux chart to v0.34.0 change log here https://github.com/fluxcd/flux2/releases/tag/v0.34.0

Is your feature request related to a problem ?

I want to run Flux with MultiTenancy Lockdown enabled. Still that is not enough for the security posture I'm looking for. Mainly because kustomize-controller and helm-controller service accounts have cluster-admin ClusterRoleBinding.

I would like to run Flux with as least privilege as possible, thus I don't want the flux service accounts to become cluster admins.

Describe the solution you'd like.

This would be fixable by adding a flag to the cluster-admin ClusterRoleBinding, the problem is that doing that, Flux wouldn't be able to do service account impersonation due to lack of permissions.

I figured out a way to do it by just adding cluster-reconciler-impersonator ClusterRole to the kustomize-controller and helm-controller.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-reconciler-impersonator
rules:
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["impersonate"]

I would add a privileged flag to the multi-tenancy section on flux chart, like:

# -- Both kustomize-controller and helm-controller service accounts run privileged 
# with cluster-admin ClusterRoleBinding. Disable if you want to run them with a 
# minimum set of permissions.
privileged: true

And then give kustomize-controller / helm-controller service accounts the cluster-admin ClusterRoleBinding if Flux runs in privileged mode or give the cluster-reconciler-impersonator ClusterRoleBinding if it runs unprivileged.

I've tested this myself and it works nicely.

Describe alternatives you've considered.

Doing Helm Post Render to remove cluster-admin ClusterRoleBinding and making use of extraObjects to render out the impersonator ClusterRole and ClusterRoleBinding.

Additional context.

No response

Is your feature request related to a problem ?

No problem, just keep up with the latest version released.

Describe the solution you'd like.

Update the chart to use the new version

Describe alternatives you've considered.

None

Additional context.

Ref: https://github.com/fluxcd/flux2/releases/tag/v0.23.0

Is your feature request related to a problem ?

When installing the chart on an AKS cluster with an Azure Firewall as egress, the Helm install fails with the following log in the flux-check job:

Kubernetes API call failed: Get "https://10.0.0.1:443/version": EOF

The IP address 10.0.0.1 is being pulled from the KUBERNETES_SERVICE_HOST env variable that is set.

To set the env variables to use the FQDN instead of IP addresses, Microsoft has released an annotation:

 kubernetes.azure.com/set-kube-service-host-fqdn: "true"

Describe the solution you'd like.

The ability to add annotations in the Flux2 Chart pre-install-job.yaml file under spec.template.metadata.

Describe alternatives you've considered.

Setting environment variables directly which also isn't supported and a bit more challenging as that would require the API address to be passed in.

Additional context.

No response

Is your feature request related to a problem ?

Unable to use flux helm chart out of the box when targeting a corporate GitRepository (corporate ca for tls access)
Same for notification controller when targeting corporate mattermost

Describe the solution you'd like.

Id like to be able to set wether;

• corporate ca to use for source controller
• volumes/volumes mount for source controller

Describe alternatives you've considered.

Currently using a Kyverno policy to set the additional volume / volumeount for our corporate ca.
This is quite specific to our environement and requires kyverno before installing flux helm chart ....

Additional context.

No response

Is your feature request related to a problem ?

no

Describe the solution you'd like.

generate helmchart version with semVersion via Makefile/pre-commit

https://github.com/fluxcd-community/helm-charts/blob/main/charts/flux2/Chart.yaml#L5
implement checks that we can consider the version bump

• if generator creates new crds, imageTags // step=minor
• t.b.d

example for version bump via script:

RE='[^0-9]*\([0-9]*\)[.]\([0-9]*\)[.]\([0-9]*\)\([0-9A-Za-z-]*\)'

step="$1"
if [ -z "$1" ]
then
  step=patch
fi

base=$(cat charts/flux2/Chart.yaml | grep "version:" | cut -c10-)
MAJOR=`echo $base | sed -e "s#$RE#\1#"`
MINOR=`echo $base | sed -e "s#$RE#\2#"`
PATCH=`echo $base | sed -e "s#$RE#\3#"`

case "$step" in
  major)
    let MAJOR+=1
    let MINOR=0
    let PATCH=0
    ;;
  minor)
    let MINOR+=1
    let PATCH=0
    ;;
  patch)
    let PATCH+=1
    ;;
esac

echo "$MAJOR.$MINOR.$PATCH"

in all cases the testfiles needs to be updated as well:
example for one testfile:
https://github.com/fluxcd-community/helm-charts/blob/main/charts/flux2/tests/__snapshot__/helm-controller_test.yaml.snap#L10
https://github.com/fluxcd-community/helm-charts/blob/main/charts/flux2/tests/__snapshot__/helm-controller_test.yaml.snap#L12

Describe alternatives you've considered.

no

Additional context.

No response

The flux2-sync chart is using a deprecated API for GitRepositories, please update it to v1beta2.

Is your feature request related to a problem ?

While using flux2-sync chart the naming of the file kustomization.yaml is causing problems during automations where by convention it is considered to be kustomization file of apiVersion: kustomize.config.k8s.io/v1beta1.
So, we get the error: json: unknown field \"spec\"

Describe the solution you'd like.

We could rename the file kustomization.yaml to sync-kustomization.yaml or something else.

Describe alternatives you've considered.

After the manifests are generated using helm template, manually renaming the file kustomization.yaml fixes the problem.

Additional context.

One example would be,

we could give the path of flux2-sync-templates as the kustomization path for a flux deployment, in such cases kustomization.yaml generated by flux2-sync helm chart.
In such cases, we get the error

couldn't make target for path '/tmp/kustomization-3076028919/development/application/flux2/charts/flux2-sync/templates': json: unknown field \"spec\"

Describe the bug a clear and concise description of what the bug is.

I'm struggling setting a multiline git ignore configuration like:

gitRepository:
  spec:
    url: repository_url
    ref: {"branch": "branch"}
    ignore: |
      # exclude all
      /*
      # include deploy dir
      !/cluster-name/fluxcd-applications

This results in:

Error: YAML parse error on flux2-sync/templates/flux-gitrepository.yaml: error converting YAML to JSON: yaml: line 20: could not find expected ':'

What's your helm version?

3.9.4

What's your kubectl version?

v1.24.3

What's the chart version?

1.0.0

What happened?

No response

What you expected to happen?

No response

How to reproduce it?

No response

Enter the changed values of values.yaml?

gitRepository:
spec:
ignore: |
# exclude all
/*
# include deploy dir
!/cluster-name/fluxcd-applications

Enter the command that you execute and failing/misfunctioning.

helm upgrade -n flux-system -f x fluxcd-apps fluxcd-community/flux2-sync

Anything else we need to know?

No response

Is your feature request related to a problem ?

Currently, when we use the flux-sync chart, we are given the option of creating the secret in the desired cluster. When we use Crossplane, we have to provide the secret data that we want the chart to create. But it isn't possible to create those keys in the Crossplane composition and pass them into the flux-sync chart.

Describe the solution you'd like.

Can we implement functionality that allows this chart to create those keys if specified? We could then use a kubernetes provider in Crossplane to retrieve the public key to then use it further in the composition when creating deploy keys in Gitlab / Github.

Describe alternatives you've considered.

I've tried to use the terraform Crossplane provider, with the tls provider in Terraform to generate those keys.

          forProvider:
            source: Inline
            module: |
              // Outputs are written to the connection secret.
              output "private_key" {
                value       = tls_private_key.flux_deploy_keys.private_key_pem
                sensitive = true
              }
              output "public_key" {
                value       = tls_private_key.flux_deploy_keys.public_key_pem
                sensitive = false
              }
              resource "tls_private_key" "flux_deploy_keys" {
                algorithm   = "ECDSA"
                ecdsa_curve = "P256"
              }

However, the private_key (because it is marked as sensitive) is output into the connection details secret which means I cannot retrieve the value for the flux-sync Chart. Pending crossplane/crossplane#2772.

Additional context.

We are trying to create clusters and install Flux onto those clusters with Crossplane. We can create the cluster, install Flux on it, but we cannot create / give the asymmetric keys to the flux-sync Helm Chart that is used to create the flux-system secret that the source-controller needs in order to clone the repo.

Please update the flux2 chart to match the v0.30.2 release. Note that v0.30 comes with RBAC, CRDs and controller's flag changes.

Can they be separated to have a single manifest template?

Created this issue to remind me about #1 (comment)

I will like to have an option like this jetstack/cert-manager@master/deploy/charts/cert-manager/values.yaml#L42

Created this issue to remind me about #1 (comment)

With Helm OCI being GA, I think we should also publish the charts to GitHub Container Registry. An example of how to push to GHCR from GH Actions can be found here: https://github.com/stefanprodan/podinfo/blob/master/.github/workflows/release.yml#L71

PS. After we push the charts to GHCR, we need to use the GH UI and make the images public.

prepare helm-chart for upstream flux2 0.26 release
fluxcd/flux2#2308

Is your feature request related to a problem ?

We need configure https_proxy for source controller to get those sources, but the deployment does't accept extra env vars.

Describe the solution you'd like.

Add value extraEnv in the controller deployment.

Describe alternatives you've considered.

None

Additional context.

No response

Describe the bug a clear and concise description of what the bug is.

In flux-sync in values.yaml in gitRepository, the ref field expects a string value,
but in gitRepository templates it expects a map value.
ref: mybranch
Also I tried to put a map in values.yaml, for example:

ref:
  branch: mybranch

but I got the same error as specifying just an string.

Error: Failed to render chart: exit status 1: coalesce.go:202: warning: destination for ref is a table. Ignoring non-table value
Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: ValidationError(GitRepository.spec.ref): invalid type for io.fluxcd.toolkit.source.v1beta1.GitRepository.spec.ref: got "string", expected "map"

What's your helm version?

version.BuildInfo{Version:"v3.7.1", GitCommit:"1d11fcb5d3f3bf00dbe6fe31b8412839a96b3dc4", GitTreeState:"clean", GoVersion:"go1.16.9"}

What's your kubectl version?

Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.3", GitCommit:"c92036820499fedefec0f847e2054d824aea6cd1", GitTreeState:"clean", BuildDate:"2021-10-27T18:41:28Z", GoVersion:"go1.16.9", Compiler:"gc", Platform:"darwin/amd64"}

What's the chart version?

flux2-sync-0.1.1

What happened?

In flux-sync in values.yaml in gitRepository, the ref field expects a string value,
but in gitRepository templates it expects a map value.
ref: mybranch
Also I tried to put a map in values.yaml, for example:

ref:
  branch: mybranch

but I got the same error as specifying just an string.

Error: Failed to render chart: exit status 1: coalesce.go:202: warning: destination for ref is a table. Ignoring non-table value
Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: ValidationError(GitRepository.spec.ref): invalid type for io.fluxcd.toolkit.source.v1beta1.GitRepository.spec.ref: got "string", expected "map"

What you expected to happen?

I expect following command is success:
helm diff upgrade -n flux2 -f flux2-sync-values.yaml flux2-sync fluxcd-community/flux2-sync

How to reproduce it?

Specify a string value for ref field.

Enter the changed values of values.yaml?

ref: mybranch

or

ref:
branch: mybranch

Enter the command that you execute and failing/misfunctioning.

helm diff upgrade -n flux2 -f flux2-sync-values.yaml flux2-sync fluxcd-community/flux2-sync

Anything else we need to know?

No response

Please update the Flux chart to v0.36.0 change log here https://github.com/fluxcd/flux2/releases/tag/v0.36.0

Is your feature request related to a problem ?

Currently, after #102 was merged, it is now possible to allow the flux-sync helm chart create (using the flux-cli) the SSH keys that would be used to push and pull to Git. However, for use in Crossplane (where I am using it), there is no way of getting the identity.pub where I can pass it to a Gitlab provider to create the Deploy key.

Describe the solution you'd like.

In spirit of "if you don't ask you don't get" (although in this case, I think I know what the answer is), do people feel it would be possible to create another wrapper around the flux-cli where it only creates the deploy key to gitlab / github based on the SSH keys it created previously? Currently, reading the docs, it doesn't seem that there is a dedicated command on the flux-cli and only possible via the flux bootstrap command?, but wondering if there was another way someone felt this would be possible? This would reduce complexity in the flavours of Crossplane compositions (see below) that attempts to install Flux, and the SSH keys and create the DK in the relevant Git repository. Instead, there would only need to be a flux-install and a flux-sync step, and no others.

Describe alternatives you've considered.

Several flavours in Crossplane

1. Key creation via Terraform:

• Create keys using TLS terraform provider inside the Terraform Crossplane provider where the keys are output to a connectionDetailsSecret
• Try to reference the keys created via Terraform, in the flux-sync resource - but not possible to do yet as connectionDetailsSecret aren't referenceable in Crossplane resources yet. crossplane/crossplane#2772
• Downsides:
  - The known hosts have to be provided manually

2. Let flux-sync create the SSH keys

• Use the flux-sync Chart to create the keys and known_hosts in remote cluster
• Use K8s crossplane provider to retrieve the identity.pub from remote cluster and share it with a Gitlab crossplane provider in order to create the deploy key
• Downsides
  - Current implementation of K8s provider does not allow for access of Objects from remote clusters crossplane-contrib/provider-kubernetes#41
• Current implementation of Gitlab providers doesn't allow for DK's to be created crossplane-contrib/provider-gitlab#13

Additional context.

No response

Is your feature request related to a problem ?

I think it will be nice to see in this chart a possibility to add additional args to containers. Sometimes Flux developers add new flags to services but describe everything can be not so good, so maybe it will be a good option for such cases.
I can create a pull request for it.

Describe the solution you'd like.

Something like this

      containers:
      - args:
        - --events-addr={{ .Values.eventsaddr }}
        - --watch-all-namespaces={{ .Values.watchallnamespaces }}
        - --log-level={{ .Values.loglevel | default "info" }}
        - --log-encoding=json
        - --enable-leader-election
        {{- range .Values.imagereflectorcontroller.container.additionalargs }}
        - {{ . }}
        {{- end}}

Describe alternatives you've considered.

Maybe it is worth to add it across all containers.

Additional context.

No response

Thanks for these charts. I always found the flux bootstrap a bit of magical complex install process and the terraform flux provider unable to handle upgrades.

Is your feature request related to a problem ?

Currently helm3 when doing an upgrade doesn't upgrade custom resources which can lead to deployment failures because custom resources are not upgraded.

Describe the solution you'd like.

I suggest creating in the repo a crds directory and a crds_0.24.0.yaml file with the crds definitions for each chart release.
then it will be possible to just download the file and then do a
helm apply -f crds_0.24.0.yaml
before doing the helm upgrade
if you think thats a good idea then i can create a PR.

Describe alternatives you've considered.

alternatively you need to download the chart and extract the crds into file(s) and apply them not a big deal i guess but easy to forget.
We could just add docs in the readme of that process to remind folks instead of providing the crds file/

Additional context.

No response

To ensure the cluster is compatible with Flux, we could use the ghcr.io/fluxcd/flux-cli:v0.23.0 image in a Kubernetes Job that runs flux check --pre. The job could be configured as a pre-install hook.