On Mon, 5 Aug 2019 at 10:59, Alexander Bokovoy <abokovoy(a)redhat.com> wrote:
On ma, 05 elo 2019, Clement Verna wrote:
>On Sun, 4 Aug 2019 at 18:17, Peter Robinson <pbrobinson(a)gmail.com> wrote:
>>
>> >> On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek
>> >> <zbyszek(a)in.waw.pl> wrote:
>> >> >
>> >> > On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote:
>> >> > > I've already done some experiments with that. I used
multi-stage builds
>> >> > > with podman, but it's the same in principle. And yes, the
sizes are
>> >> > > smaller. What was interesting though that some additional
packages (ones
>> >> > > that wouldn't appear in the images using the Fedora base
image) has been
>> >> > > dragged in as dependencies. Some of them are even related to
hardware. (See
>> >> > > the report [1] and the github repo [2].)
>> >> >
>> >> > It'd be nice to rebase this to F30 or even F31. F29 is not
interesting
>> >> > anymore.
>> >> >
>> >> > A lot of the stuff in those images seems completely unnecessary:
>> >> > device-mapper, device-mapper-libs, dracut, cpio,
glibc-all-langpacks,
>> >> > grubby, systemd-bootchart, systemd-udev.
>> >> >
>> >> > > So that might be one area to focus on — to make sure that
these "from
>> >> > > scratch" installations don't drag unnecessary
stuff.
>> >> >
>> >> > Yep, that sounds like a good start. I suspect that F30 might be
already
>> >> > better in this regard.
>> >>
>> >> Yes quite a bit has happened on the base image since F29, we have
>> >> removed quite a few things and trimmed down the latest rawhide to
>> >> 208MB. I am sure that can still be improved and I welcome any help on
>> >> that :-).
>> >
>> >
>> > I've regenerated it for f30 and f31:
https://asamalik.fedorapeople.org/container-randomness/report.html
>> >
>> > I see the fedora:f31 image is 195 MB, woot!
>>
>> Is there a plan to add some form of CI to monitor this? It would make
>> it easy to monitor ups/downs over time and pick up mistakes that bloat
>> deps by accident.
>
>I started some effort in that sense last year, to have the Fedora CI
>pipeline to trigger on container builds[0]. Unfortunately the CI
>pipeline for containers is not working [1] and it seems that nobody
>has cycles to try to fix it.
>We could also get some inspiration from what the Docker Hub folks are
>doing [2][3].
>
>And finally I would love to sunset registry.fp.o and just use quay.io
>as our main registry that would give us for CVE scanning for free
>using Clair[4] (that would also be one less thing to care about on the
>infra side), but here again there is some work to be done to make that
>possible :-)
Do we have all the same containers in quay.io?
FreeIPA upstream is relying on Fedora toolbox and main Fedora containers
for its CI testing in Azure Pipelines. I cannot find Fedora toolbox in
quay.io/fedora/ project.
Nope and that's what I meant by saying that this needs some works to
make it possible :-) (Pretty much configure OSBS to publish images to
quay.io instead of registry.fp.o). We also need to make sure that we
can deliver flatpaks from quay.io.
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: