Description of problem: when I docker push on Fedora it is trying to push to registry.redhat.com. This is not the behavior in fedora 25. I assume it is a mistake and the configuration needs to be taken out. ``` [root@vanilla-f26atomic ~]# docker push dustymabe/fedora-min The push refers to a repository [registry.access.redhat.com/dustymabe/fedora-min] 6d6fcb84c31f: Preparing error parsing HTTP 405 response body: invalid character '<' looking for beginning of value: "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 3.2 Final//EN\">\n<title>405 Method Not Allowed</title>\n<h1>Method Not Allowed</h1>\n<p>The method POST is not allowed for the requested URL.</p>\n" ``` Version-Release number of selected component (if applicable): docker-1.13.1-3.git5be1549.fc26.x86_64
This has changed in https://bugzilla.redhat.com/show_bug.cgi?id=1384202 Even if the related bug says "for searching purposes" afaict, there's no way to tell docker to just use the RH registry to search for images. Hence we added that. I'm not sure what to do here honestly. My preference would be to drop this from Fedora. Both Dan(s), what do you think?
Well this would be an issue with RHEL also. If we setup the tools to --block-registry=all --add-registry registry.access.redhat.com --add-registry=docker.io Does this fix the issue, where I can continue to pull from redhat or docker and default to pushing to docker.io?
even if we are able to achieve that behavior do we really want to default to pulling from the red hat registry when the openness of that registry could change?
You can get credentials for RHEL on a Fedora host, so you could get a developer license and use that content. Daniel Riek requested that change for that reason. Bottom line is we have the same issue on RHEL systems. Dusty could you make the change to the /etc/sysconfig/docker and see if it solves your issue.
(In reply to Daniel Walsh from comment #2) > Well this would be an issue with RHEL also. If we setup the tools to > > --block-registry=all --add-registry registry.access.redhat.com > --add-registry=docker.io > > Does this fix the issue, where I can continue to pull from redhat or docker > and default to pushing to docker.io? Dan, I wouldn't block all registries. That means the user could just push/pull/search on RH registry and docker.io - which seems weird in Fedora at least. I'll check how this impacts RHEL though (hadn't a chance till now). To summarize: - the original BZ wanted the ability to __docker search__ the RH registry for images (nothing to do with push/pull) - the original BZ resolution added the rhel registry as the default one, making pushing images just go to the RH registry (which is plain wrong to me, both in RHEL and Fedora) - so, let's check if pushing an unqualified image in RHEL with the default add-registry causes the push to go to the RH registry (which will fail as it's read-only) - to workaround the point above, one could push with a qualified image (e.g. docker push docker.io/myawesomeimage - research if it could be possible to enhance the registry patch we carry to search on additional registries w/o impacting push/pull operations
(In reply to Daniel Walsh from comment #2) > Well this would be an issue with RHEL also. If we setup the tools to > > --block-registry=all --add-registry registry.access.redhat.com > --add-registry=docker.io > > Does this fix the issue, where I can continue to pull from redhat or docker > and default to pushing to docker.io? No, even with those options I still default to pointing to registry.access.redhat.com.
I'll still say I think that all we should do is add a flag to disable the "foo" → "docker.io/foo" auto-mapping. With that flag on, *everyone* is on equal terms. Yes, indeed this means people will need to type: docker pull registry.access.redhat.com/rhel7, but the solution to that is to shorten the URL IMO (redhat.io/rhel7) ? Searching registry.access.redhat.com but *not* registry.fedoraproject.org seems weird to me for example.
Also, with this flag it's then `docker search -r/--registry docker.io term1 term2` ?
The only downside to a flag which removes the auto-mapping is that we'll break *lots* of people/customers who have "FROM fedora" in their Dockerfiles.
Not just Dockerfiles of course, but Kubernetes pod definitions etc etc. But we only have to pull the bandaid off once. And don't we want people saying `FROM registry.fedoraproject.org/fedora` Or alternatively, `docker.io/fedora`. Note I'm not arguing for having this flag on by default. What I am arguing is we should: - Implement it, including the `docker search --registry <registry>` - Encourage people to use it, and gradually fix up our own Dockerfiles/"Kubefiles" - Don't add hacks that muddy the waters like injecting "our own" registries - that gets into messy (and political) topics like search priorities. Even among our 3 distributions! With the "no auto-docker.io" flag, everyone is equal.
Kubernetes always pulls with the fully qualified name, This only applies to the docker CLI.
Are there not plenty of kube yaml files that people use that don't use the fully qualified name? My experience has been that specifying just 'fedora' would work when defining a pod in kube land. Maybe my memory serves me wrong.
Well that would be a problem as we move to alternative CRI like CRI-O and RKT which certainly do not have a hard coded docker.io in them.
If we can't find a solution to this problem soon, can we remove the push plugin from Fedora until a proper solution is found?
(In reply to Dusty Mabe from comment #16) > If we can't find a solution to this problem soon, can we remove the push > plugin from Fedora until a proper solution is found? we need to remove the "--add-registry" stuff from /etc/sysconfig/docker - this issue seems unrelated to the docker push plugin.
(In reply to Antonio Murdaca from comment #17) > we need to remove the "--add-registry" stuff from /etc/sysconfig/docker - > this issue seems unrelated to the docker push plugin. oops, sorry. Thought it was related.
(In reply to Daniel Walsh from comment #2) > Well this would be an issue with RHEL also. If we setup the tools to > > --block-registry=all --add-registry registry.access.redhat.com > --add-registry=docker.io > > Does this fix the issue, where I can continue to pull from redhat or docker > and default to pushing to docker.io? This works if I explicitly add docker.io as the first --add-registry by having the following in my /etc/sysconfig/docker: ADD_REGISTRY='--add-registry docker.io --add-registry registry.access.redhat.com' I did not apply --block-registry=all. I was also able to pull from the different registries, but it will try them in order.
(In reply to Dusty Mabe from comment #19) > (In reply to Daniel Walsh from comment #2) > > Well this would be an issue with RHEL also. If we setup the tools to > > > > --block-registry=all --add-registry registry.access.redhat.com > > --add-registry=docker.io > > > > Does this fix the issue, where I can continue to pull from redhat or docker > > and default to pushing to docker.io? > > This works if I explicitly add docker.io as the first --add-registry by > having the following in my /etc/sysconfig/docker: > > ADD_REGISTRY='--add-registry docker.io --add-registry > registry.access.redhat.com' > The question is - is this configuration searching in our RH registry when someone does "docker search rhel"? or it goes just to docker.io (which was why the RH registry was added first)
Created attachment 1267131 [details] dockersearch.txt It searches both registries, but the (potentially disturbing) docker.io results are first.
This is ok for now, and I think we should add a new field, --default-pushregistry or something like that so that you can specify multiple read registries in order and one default push reg.
docker-1.13.1-6.git5be1549.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-80cdb3361d
docker-1.13.1-6.git5be1549.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-80cdb3361d
docker-1.13.1-6.git5be1549.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
I am stil seeing this on F26 with package docker-1.13.1-19.git27e468e.fc26.x86_64 I have some images on docker.io but after upgrading to F26 docker push is using registry.fedoraproject.org I guess the work-around (getting same behaviour as in F25) for this, is to add docker.io as first entry in /etc/containers/registries.conf ?
(In reply to Dennis Schafroth from comment #26) > I am stil seeing this on F26 with package > docker-1.13.1-19.git27e468e.fc26.x86_64 > > I have some images on docker.io but after upgrading to F26 docker push is > using registry.fedoraproject.org > > I guess the work-around (getting same behaviour as in F25) for this, is to > add docker.io as first entry in /etc/containers/registries.conf ? Removing all the entries for redhat/fedora in /etc/containers/registries.conf is a workaround in F26
You can also change the order in registries.conf.
For people who agree with me, all you need to do is change /etc/containers/registries.conf to read: [registries.search] registries = [] Then fully qualified image names will always be required and you'll never be confused about where images come from.