-
Notifications
You must be signed in to change notification settings - Fork 203
Flux fails to login to HTTP OCI registry where helm CLI logs in #805
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
Comments
A comment after looking at the code. The difference between when the
In order to try both endpoints, Flux does not support the insecure option yet. I will add a separate issue to track that enhancement. edit: issue is #807 |
Also this: // Localhost is by default considered as an insecure registry
// This is a stop-gap for people who are running a private registry on localhost (especially on Boot2docker).
//
// TODO: should we deprecate this once it is easier for people to set up a TLS registry or change
// daemon flags on boot2docker?
registries = append(registries, "127.0.0.0/8") That explains why it tried both endpoints. It has to do with the |
I did not. Commands were issues exactly as I've stated above. Its a copy and paste from my terminal
👍 That's another long standing issue with flux I've had. Thanks for filing it, saves me work |
Describe the bug
opening an issue per @souleb 's request. Slack discussion here
Excerpts:
Hello
trying to confirm whether this is a bug:
I have deployed helm's OCI registry from (described here https://helm.sh/docs/topics/registries/) into my kind k8s cluster.
I have configured it to have a single authorized user: username foo, password bar
The deployment is exposed as a service like this:
i.e. accessible within the cluster as registry-app-svc.default.svc.cluster.local:5000/helm-charts
sure enough, I can open a new shell into the cluster and do this:
This is all as expected. Now, if I port-forward 5000 from the cluster to my localhost (client) like this
$ kubectl port-forward --namespace default service/registry-app-svc 5000:5000
I can also do
So far so good. Notice the INFO message above, I think it is key here.
I can also use other helm registry commands such as:
Now if I create a secret like this:
followed by
I get an error:
and the HelmRepository CRD is stuck in a failed state:
It seems to me that flux source controller tries to communicate via HTTPs, fails and gives up.
Compare that to helm client which also gets an error but then tries plain HTTP and it works
I can provide much more detailed repro steps if needed.
Thanks in advance for consideration
Greg
my environment:
...
As an end user I like the fact that helm cli does not require me to know what's behind the OCI registry. helm client allows me to work with both registeries that require HTTPs (ghcr.io) and require HTTP (this sample registry image from docker). I don't need to know. Period. Are you sure you want fluxcd to work differently than helm CLI? That seems an odd choice to me - I would think fluxcd would want to be consistent with helm CLI and not burden the end user with this. Just a thought
Steps to reproduce
see above
Expected behavior
see above
Kubernetes version / Distro / Cloud provider
kind
Flux version
see above
Git provider
see above
Container Registry provider
see above
Additional context
see above
Maintenance Acknowledgement
Code of Conduct
The text was updated successfully, but these errors were encountered: