flux-recv
flux-recv copied to clipboard
fluxcd
non-sidecar installation
It appears that one cannot run flux-recv unless it is a sidecar because it connects to localhost:3030.
I see how to overwrite it. However, this is a bit indirect. It would be better to expose the API as an env variable don't you think?
It would be better to expose the API as an env variable don't you think?
Why?
It is a style choice, so feel free to ignore, but there is a camp that avoids aggregating config info into a single Json structure and instead passes individual flat env variables.
I see, OK. My reasoning was: it will be convenient to provide keys as files, and if the config refers to those files, it's probably best that it's a file as well.
It's arguable in the case of the API, perhaps, since that is more like a command-line argument in a way. I certainly take your point that it could be more obvious where it's configured :-)
@squaremo It would really be helpful to separate out the location of fluxrecv into a configmap.
Here is why.
I pull secrets from an external store. I have a script that can easily switch from sidecar to non-sidecar simply by changing K8s manifests. The problem is that I must also change where fluxrecv is. So, I must either use another secret name or I must change the secret that is stored externally. If you split out the location into a configmap, then I could easily generate the new config map.
Also, while sidecar use may be preferred, it is problematic when bootstrapping flux because then the bootstrapping process needs access to the fluxrecv secret.
It would really be helpful to separate out the location of fluxrecv into a configmap.
What do you mean by "location" here?
[running as a sidecar to fluxd] is problematic when bootstrapping flux because then the bootstrapping process needs access to the fluxrecv secret.
Let me see if I understand this problem: when running flux-recv as a container in the same pod as fluxd, the pod won't start if the secret for flux-recv is missing. So you have to provision it out-of-band, which means extra work.
Does that sound right, or is your objection something else?
@derrickburns, this may not be an acceptable trade-off, but you can mark Secrets and ConfigMaps as optional. See SecretVolumeSource from v1 core: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#secretvolumesource-v1-core
It's the subType that's used for pod.spec.volumes and pod.spec.containers[].envFrom.
In Flux v2, notification-controller is a standalone entity and no longer behaves as a sidecar.
This works well with SOPS encrypted secrets, from my own testing of Flux v2. I have a notification-controller in my multi-tenant (OpenShift-based) Flux installation, in the user namespace, (it is configured through a configmap) and it apparently does all the jobs, because I connected it to 4 GitRepositories through a Receiver, with no issues, through an ingress route.
It even correctly returns 400 status when some of the GitRepositories are missing, and couldn't be notified.
(Recommend to close this issue and add the flux2 label, which I am using to indicate when an issue is resolved recommending to upgrade, to collect together and turn into a document about why Flux users should want to upgrade to Flux 2!)
If I can be given the same role here on flux-recv as I have been given on the flux, helm-operator repos, I'll be happy to close this one out and add the label. I think it is just just the write access role, (the triage role also enables to control labels.)
