Open mwilck opened 2 years ago
I'm sorry that I have to close this, but we are tracking issues in the source code in here. Github issues are not a way to request support from us. If you a have problem with a specific instance, contact the administrators of it.
Thank you for your consideration.
registry.suse.com is configured and the right path is added. However, I have no time atm to debug it.
But reopen it for now because it could be an OBS bug at least...
What's missing in this report is that this is on IBS, where registry.suse.com
should be ignored and it should use the container binaries in the build path instead.
That's not how it works. If you specify registry.suse.com, you'll get the container from it. (Except that it does not work in IBS, because of missing configuration in the Templates project).
That's not how it works.
That's how it worked before remote registry support was added.
If you specify registry.suse.com, you'll get the container from it. (Except that it does not work in IBS, because of missing configuration in the Templates project).
Our use case is that within OBS it uses the binaries available there, which can be newer than the ones on the registry. That should be the case without changing the Dockerfile/.kiwi.
It only worked if there was no "registry.suse.com" prefix. And that's still the case.
Unless my memory is wrong, OBS used to just ignore the host part of references.
I'm pretty sure your memory is wrong. ;-)
Ok, in that case I suppose it's not a regression report but a feature request...
That's not how it works. If you specify registry.suse.com, you'll get the container from it. (Except that it does not work in IBS, because of missing configuration in the Templates project).
Am I understanding correctly that this could be fixed on IBS by modifying the repository configuration? E.g. by adding "SUSE:Registry"?
That's not how it works. If you specify registry.suse.com, you'll get the container from it. (Except that it does not work in IBS, because of missing configuration in the Templates project).
Am I understanding correctly that this could be fixed on IBS by modifying the repository configuration? E.g. by adding "SUSE:Registry"?
Yes, but that then builds against the published containers but uses the internal SLE binaries. That breaks in some cases. 15 SP5 doesn't have any containers published yet for instance.
Adding SUSE:Registry did the trick.
Yes, but that then builds against the published containers but uses the internal SLE binaries. That breaks in some cases
But it's understandable that this wouldn't work with the registry.suse.com/
prefix. Perhaps we should use some other prefix for that, like ibs.suse.de/
or what not.
Adding SUSE:Registry did the trick.
Yes, but that then builds against the published containers but uses the internal SLE binaries. That breaks in some cases
But it's understandable that this wouldn't work with the
registry.suse.com/
prefix. Perhaps we should use some other prefix for that, likeibs.suse.de/
or what not.
Then it would not build on OBS or with docker build
.
Then it would not build on OBS or with
docker build
.
Right, but you'd be using a feature that's really available only on OBS.
@Vogtinator, maybe you should just add "SUSE:Registry" to the path list in the Templates repo. That would fix the problem that registry.suse.com/
paths don't work. Users who need to use the latest internal builds could still switch to the prefix-less variant.
That's not how it works.
That's how it worked before remote registry support was added.
If you specify registry.suse.com, you'll get the container from it. (Except that it does not work in IBS, because of missing configuration in the Templates project).
Our use case is that within OBS it uses the binaries available there, which can be newer than the ones on the registry. That should be the case without changing the Dockerfile/.kiwi.
@Vogtinator could you elaborate a bit on the remote registry support? I would like to have a Dockerfile
that works both in the OBS and locally. Ideally, I want to use the bci/bci-base
image from SUSE. When I don't specify the registry then it would take possibly the wrong image.
That's not how it works.
That's how it worked before remote registry support was added.
If you specify registry.suse.com, you'll get the container from it. (Except that it does not work in IBS, because of missing configuration in the Templates project).
Our use case is that within OBS it uses the binaries available there, which can be newer than the ones on the registry. That should be the case without changing the Dockerfile/.kiwi.
@Vogtinator could you elaborate a bit on the remote registry support? I would like to have a
Dockerfile
that works both in the OBS and locally. Ideally, I want to use thebci/bci-base
image from SUSE. When I don't specify the registry then it would take possibly the wrong image.
You can just use the SLE 15 SP4 "Application Container using Dockerfile" template and change the FROM line to use registry.suse.com/bci/bci-base:15.4
.
You can just use the SLE 15 SP4 "Application Container using Dockerfile" template and change the FROM line to use
registry.suse.com/bci/bci-base:15.4
.
Wouldn't that raise the issue you mentioned above?
You can just use the SLE 15 SP4 "Application Container using Dockerfile" template and change the FROM line to use
registry.suse.com/bci/bci-base:15.4
.Wouldn't that raise the issue you mentioned above?
Yes, but on OBS that's currently not avoidable.
Yes, but on OBS that's currently not avoidable.
Perhaps not a big issue, as most Dockerfiles run "zypper up" or similar.
Issue Description
The following instruction fails on IBS, with standard containers branched from
SUSE:Templates:Images:SLE-15-SP4/dockerfile-application-container
:Error message is "
unresolvable: nothing provides container:registry.suse.com/bci/bci-base:15.4
". It works if theregistry.suse.com/
is removed.Expected Result
The container build works with the standard container path, including the registry.
How to Reproduce
See this IBS package.