Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Private OCI chart repositories not working #717

Closed
eloo-abi opened this issue Jun 19, 2024 · 4 comments
Closed

Private OCI chart repositories not working #717

eloo-abi opened this issue Jun 19, 2024 · 4 comments

Comments

@eloo-abi
Copy link

Hi,

i'm trying to get flux-local running but i'm struggling with a private OCI helm chart repo (Harbor).

I guess the issue is that the registry-config parameter is set to /dev/null
https://github.com/allenporter/flux-local/blob/main/flux_local/helm.py#L163

This also seems to block the possibility to change it using the env variable.
So i'm curious what the reason is why the registry-config is set to /dev/null?

Maybe this could be removed or at least made be configurable so its possible to use private OCI registries?

Thanks

@allenporter
Copy link
Owner

Hi, definitely open to being flexible here. The main reason this is disabled is so that helm only looks at things defined in the repository. I am not super familiar with the details of OCI other than basics to make it work, nor how to configure private repos. Happy to talk through a solution (one of the options you propose may be the right one) though may need some help understanding a little more what the workflow is supposed to look like. Can you give me a little more background on how you set this up and specify private oci helm chart repos in practice?

There is also discussion in #301 so wondering if a single approach solves both.

@eloo-abi
Copy link
Author

@allenporter okay that sounds good so far :)

For the OCI helm chart we have Harbor setup up (https://github.com/goharbor/harbor), which we also use for our docker images already.
The main idea is to reuse the OCI format to store and exchange helm chart instead of tar.gz
More detail can be found in the helm docs: https://helm.sh/docs/topics/registries/

And the issue with the hardcoded flag is that adding credentials will not work because its not used afterwards.
Normally we do

helm registry login ...

this will be written into the ~/.config/helm/registry/config.json and then reused to authenticate when calling OCI registries. (its the same format as docker/config.json

The path what file should be used to lookup registry auths can be configured with this parameter

      --registry-config string          path to the registry config file (default "~/.config/helm/registry/config.json")

And there is the problem because this is hardcoded to /dev/null right now ans so its not possible to use private OCI.

I guess the best solution without a breaking change would be to expose this parameter to the flux-local cli and keep /dev/null as default.
So i could be set if necessary but if not needed nothing is going to be changed.

As #301 is referring to "http" charts i'm not sure if this would fix it here as well. But i would expect that helm repo add ... --username --password should work already.

If not exposing

      --repository-config string        path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml")

could be the fix here as well.

Best regards

@eloo-abi eloo-abi reopened this Jun 20, 2024
allenporter added a commit that referenced this issue Jun 29, 2024
Add a flag `--registry-config` that can be used as a pass through to the
helm command.

#717
#301
@allenporter
Copy link
Owner

I've added a --repository-config in 5.4.0. Will mark as closed but repoen if there is a problem using it.

@eloo-abi
Copy link
Author

eloo-abi commented Jul 8, 2024

@allenporter i've just tested the lastest version and it works now for our setup with private OCI chart repos

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants