7:01 a.m.
I have a docker recipe that does not much more than:
FROM fedora:rawhide
RUN dnf -y install ...blah...
If I run this from a Fedora host it works fine, resolving fedora:rawhide
to registry.fedoraproject.org image ID 23902052bc28
If I run this from a non-Fedora host, such as from GitLab CI, it resolves
to docker.io/library image ID e6ff04a4b8bd.
The latter image fails when installing RPMs due tpo missing gpg keys
# dnf install numactl
Fedora 33 openh264 (From Cisco) - x86_64 5.2 kB/s | 5.1 kB 00:00
Fedora - Modular Rawhide - Developmental packages for the next 1.9 MB/s | 961 kB 00:00
Fedora - Rawhide - Developmental packages for the next Fedora 12 MB/s | 73 MB 00:06
Dependencies resolved.
===============================================================================================
Package Architecture Version Repository
Size
===============================================================================================
Installing:
numactl x86_64 2.0.12-6.fc33 rawhide
69 k
Installing dependencies:
numactl-libs x86_64 2.0.12-6.fc33 rawhide
30 k
Transaction Summary
===============================================================================================
Install 2 Packages
Total download size: 99 k
Installed size: 238 k
Is this ok [y/N]: y
Downloading Packages:
(1/2): numactl-2.0.12-6.fc33.x86_64.rpm 543 kB/s | 69 kB 00:00
(2/2): numactl-libs-2.0.12-6.fc33.x86_64.rpm 207 kB/s | 30 kB 00:00
-----------------------------------------------------------------------------------------------
Total 219 kB/s | 99 kB 00:00
warning:
/var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages/numactl-2.0.12-6.fc33.x86_64.rpm: Header
V4 RSA/SHA256 Signature, key ID 45719a39: NOKEY
Fedora - Rawhide - Developmental packages for the next Fedora 1.6 MB/s | 1.6 kB 00:00
GPG key at file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64 (0x9570FF31) is already
installed
The GPG keys listed for the "Fedora - Rawhide - Developmental packages for the next
Fedora release" repository are already installed but they are not correct for this
package.
Check that the correct key URLs are configured for this repository.. Failing package is:
numactl-2.0.12-6.fc33.x86_64
GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
Public key for numactl-libs-2.0.12-6.fc33.x86_64.rpm is not installed. Failing package is:
numactl-libs-2.0.12-6.fc33.x86_64
GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: GPG check FAILED
I can see the docker.io image has older packages
# rpm -q fedora-release-container fedora-gpg-keys
fedora-release-container-33-0.9.noarch
fedora-gpg-keys-33-0.8.noarch
than the registry.fedoraproject.org image
# rpm -q fedora-release-container fedora-gpg-keys
fedora-release-container-33-0.13.noarch
fedora-gpg-keys-33-0.11.noarch
Looking at https://hub.docker.com/_/fedora?tab=tags I see the rawhide
image is over a month out of date.
As a workaround I tried adding
dnf update -y --nogpgcheck fedora-gpg-keys
and this pulls in fedora-gpg-keys-34-0.1.noarch on docker.io images, and
does nothing on registry.fedoraproject.org images.
Even after the fedora-gpg-keys update, I still get gpg errors installing
RPMs.
Why is docker.io registry lagging so far behind registry.fedoraproject.org ?
Why is the registry.fedoraproject.org image seemingly attached to
F33 content, not pulling in F34 rawhide content ?
While the older docker.io image trying to use F34 rawhide content.
These inconsistency between the registries is making it really quite
painful for using Fedora rawhide images across different host OS.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
7:51 a.m.
On Wed, Aug 19, 2020 at 01:01:00PM +0100, Daniel P. Berrangé wrote:
I have a docker recipe that does not much more than:
FROM fedora:rawhide
RUN dnf -y install ...blah...
I'm not addressing the core of your email, but… using FROM fedora:rawhide
is not a good practice because of two reasons:
– it's not describing specific version. 'rawhide' is changing in time,
so your containers are not reproductible - building twice can produce
something different each time
- you do not specify full repository address, so you get whatever is
default. As you noticed, in different environemnts you get different
results.
In short, 'fedora:rawhide' is not enough to get specific image, the
result is quite random.
--
Tomasz Torcz To co nierealne – tutaj jest normalne.
tomek(a)pipebreaker.pl Ziomale na życie mają tu patenty specjalne.
7:57 a.m.
On Wed, Aug 19, 2020 at 02:51:57PM +0200, Tomasz Torcz wrote:
On Wed, Aug 19, 2020 at 01:01:00PM +0100, Daniel P. Berrangé wrote:
> I have a docker recipe that does not much more than:
>
> FROM fedora:rawhide
> RUN dnf -y install ...blah...
I'm not addressing the core of your email, but… using FROM fedora:rawhide
is not a good practice because of two reasons:
– it's not describing specific version. 'rawhide' is changing in time,
so your containers are not reproductible - building twice can produce
something different each time
That is fine - we explicitly want the content to be changing in this
case, as our goal is to make sure we always build with latest rawhide
content.
We have other CI jobs using the stable fedora release images
- you do not specify full repository address, so you get whatever is
default. As you noticed, in different environemnts you get different
results.
In short, 'fedora:rawhide' is not enough to get specific
image, the
result is quite random.
None the less, this is what users will commonly use - it is pretty
rare to find people using a full registry hostname when referencing
image.
With docker.io/library/fedora being labelled as an official repo,
I think it is surprising that it is so outdated and inconsistent
with what's on registry.fp.org. It leaves a bad impression of
Fedora's quality with users who try it :-(
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
10:07 a.m.
New subject: docker.io/library/fedora:rawhide outdated vs registry.fp.org/fedora:rawhide
On Wed, 19 Aug 2020 at 14:02, Daniel P. Berrangé <berrange(a)redhat.com>
wrote:
I have a docker recipe that does not much more than:
FROM fedora:rawhide
RUN dnf -y install ...blah...
Long story short the docker hub requires a PR to a github repo to update
the image, this PR is reviewed and merged by a person (more context [0])
so we cannot update the rawhide image nightly like we do on registry.fp.o.
After talking with the Docker folks a weekly cadence would be acceptable
for them and I think this is what we should try to do, we *just* need
someone to work on that.
Most of the release process is automated. We are basically missing some
glue to run scripts weekly and have the correct permission etc ... (more
info [1])
We are trying to restart the container SIG (we have a meeting coming this
week [2]) and I think this is the type of work that this group could be
helping with so anyone interested to help is more than welcome :-)
I Hope that helps and gives a bit more context.
Also if you want to make sure to pull the image from registry.fp.o you can
use the following `FROM registry.fedoraproject.org/fedora:rawhide` and that
will work on every system.
[0] - https://github.com/docker-library/official-images/issues/7529
[1] - https://pagure.io/releng/issue/8270
[2] - https://pagure.io/ContainerSIG/container-sig/issue/43
If I run this from a Fedora host it works fine, resolving fedora:rawhide
to registry.fedoraproject.org image ID 23902052bc28
If I run this from a non-Fedora host, such as from GitLab CI, it resolves
to docker.io/library image ID e6ff04a4b8bd.
The latter image fails when installing RPMs due tpo missing gpg keys
# dnf install numactl
Fedora 33 openh264 (From Cisco) - x86_64 5.2 kB/s |
5.1 kB 00:00
Fedora - Modular Rawhide - Developmental packages for the next 1.9 MB/s |
961 kB 00:00
Fedora - Rawhide - Developmental packages for the next Fedora 12 MB/s |
73 MB 00:06
Dependencies resolved.
===============================================================================================
Package Architecture Version
Repository Size
===============================================================================================
Installing:
numactl x86_64 2.0.12-6.fc33
rawhide 69 k
Installing dependencies:
numactl-libs x86_64 2.0.12-6.fc33
rawhide 30 k
Transaction Summary
===============================================================================================
Install 2 Packages
Total download size: 99 k
Installed size: 238 k
Is this ok [y/N]: y
Downloading Packages:
(1/2): numactl-2.0.12-6.fc33.x86_64.rpm 543 kB/s |
69 kB 00:00
(2/2): numactl-libs-2.0.12-6.fc33.x86_64.rpm 207 kB/s |
30 kB 00:00
-----------------------------------------------------------------------------------------------
Total 219 kB/s |
99 kB 00:00
warning:
/var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages/numactl-2.0.12-6.fc33.x86_64.rpm:
Header V4 RSA/SHA256 Signature, key ID 45719a39: NOKEY
Fedora - Rawhide - Developmental packages for the next Fedora 1.6 MB/s |
1.6 kB 00:00
GPG key at file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
(0x9570FF31) is already installed
The GPG keys listed for the "Fedora - Rawhide - Developmental packages for
the next Fedora release" repository are already installed but they are not
correct for this package.
Check that the correct key URLs are configured for this repository..
Failing package is: numactl-2.0.12-6.fc33.x86_64
GPG Keys are configured as:
file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
Public key for numactl-libs-2.0.12-6.fc33.x86_64.rpm is not installed.
Failing package is: numactl-libs-2.0.12-6.fc33.x86_64
GPG Keys are configured as:
file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
The downloaded packages were saved in cache until the next successful
transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: GPG check FAILED
I can see the docker.io image has older packages
# rpm -q fedora-release-container fedora-gpg-keys
fedora-release-container-33-0.9.noarch
fedora-gpg-keys-33-0.8.noarch
than the registry.fedoraproject.org image
# rpm -q fedora-release-container fedora-gpg-keys
fedora-release-container-33-0.13.noarch
fedora-gpg-keys-33-0.11.noarch
Looking at https://hub.docker.com/_/fedora?tab=tags I see the rawhide
image is over a month out of date.
As a workaround I tried adding
dnf update -y --nogpgcheck fedora-gpg-keys
and this pulls in fedora-gpg-keys-34-0.1.noarch on docker.io images, and
does nothing on registry.fedoraproject.org images.
Even after the fedora-gpg-keys update, I still get gpg errors installing
RPMs.
Why is docker.io registry lagging so far behind registry.fedoraproject.org
?
Why is the registry.fedoraproject.org image seemingly attached to
F33 content, not pulling in F34 rawhide content ?
While the older docker.io image trying to use F34 rawhide content.
These inconsistency between the registries is making it really quite
painful for using Fedora rawhide images across different host OS.
Regards,
Daniel
--
|: https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-
https://fstop138.berrange.com :|
|: https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
12:19 p.m.
On Wed, Aug 19, 2020 at 05:07:52PM +0200, Clement Verna wrote:
On Wed, 19 Aug 2020 at 14:02, Daniel P. Berrangé
<berrange(a)redhat.com>
wrote:
> I have a docker recipe that does not much more than:
>
> FROM fedora:rawhide
> RUN dnf -y install ...blah...
>
>
Long story short the docker hub requires a PR to a github repo to update
the image, this PR is reviewed and merged by a person (more context [0])
so we cannot update the rawhide image nightly like we do on registry.fp.o.
After talking with the Docker folks a weekly cadence would be acceptable
for them and I think this is what we should try to do, we *just* need
someone to work on that.
Most of the release process is automated. We are basically missing some
glue to run scripts weekly and have the correct permission etc ... (more
info [1])
We are trying to restart the container SIG (we have a meeting coming this
week [2]) and I think this is the type of work that this group could be
helping with so anyone interested to help is more than welcome :-)
I Hope that helps and gives a bit more context.
Yes, thank you, that is useful background. Quite a tedious process
docker hub requires for frequently changed images :-(
Aside from the plans you mention to do weekly updates in future, I'd
suggest doing a rawhide image update ASAP, to address the immediate
pain of "dnf update" not working due to the F33/F34 branching with
new GPG keys.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
4:14 a.m.
New subject: docker.io/library/fedora:rawhide outdated vs registry.fp.org/fedora:rawhide
On Wed, 19 Aug 2020 at 19:19, Daniel P. Berrangé <berrange(a)redhat.com>
wrote:
On Wed, Aug 19, 2020 at 05:07:52PM +0200, Clement Verna wrote:
> On Wed, 19 Aug 2020 at 14:02, Daniel P. Berrangé <berrange(a)redhat.com>
> wrote:
>
> > I have a docker recipe that does not much more than:
> >
> > FROM fedora:rawhide
> > RUN dnf -y install ...blah...
> >
> >
> Long story short the docker hub requires a PR to a github repo to update
> the image, this PR is reviewed and merged by a person (more context [0])
> so we cannot update the rawhide image nightly like we do on
registry.fp.o.
> After talking with the Docker folks a weekly cadence would be acceptable
> for them and I think this is what we should try to do, we *just* need
> someone to work on that.
> Most of the release process is automated. We are basically missing some
> glue to run scripts weekly and have the correct permission etc ... (more
> info [1])
>
> We are trying to restart the container SIG (we have a meeting coming this
> week [2]) and I think this is the type of work that this group could be
> helping with so anyone interested to help is more than welcome :-)
>
> I Hope that helps and gives a bit more context.
Yes, thank you, that is useful background. Quite a tedious process
docker hub requires for frequently changed images :-(
Aside from the plans you mention to do weekly updates in future, I'd
suggest doing a rawhide image update ASAP, to address the immediate
pain of "dnf update" not working due to the F33/F34 branching with
new GPG keys.
This is now fixed on Docker Hub
Regards,
Daniel
--
|: https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-
https://fstop138.berrange.com :|
|: https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|
1343
days inactive
1350
days old
5 comments
3 participants
participants (3)
-
Clement Verna -
Daniel P. Berrangé -
Tomasz Torcz