Hi everyone!
I'm starting a Minimization Objective [1] focusing on minimising the installation size of some of the popular apps, runtimes, and other pieces of software in Fedora.
And there is a new Minimization Team [2] forming. Members of the team will consult and work with Fedora maintainers, develop tooling and services, generate reports showing the status of the Fedora ecosystem and a comparison with other ecosystems, etc. The goal is to build an environment where it's easy for our maintainers to keep things small over time, it's not just a one-off effort. Please see the Action Plan [3] for more details.
Want to become a member? Let me know!
Cheers! Adam
[1] https://docs.fedoraproject.org/en-US/minimization/ [2] https://docs.fedoraproject.org/en-US/minimization/team/ [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
On Tue, Jul 30, 2019 at 10:58 AM Adam Samalik asamalik@redhat.com wrote:
Hi everyone!
I'm starting a Minimization Objective [1] focusing on minimising the installation size of some of the popular apps, runtimes, and other pieces of software in Fedora.
And there is a new Minimization Team [2] forming. Members of the team will consult and work with Fedora maintainers, develop tooling and services, generate reports showing the status of the Fedora ecosystem and a comparison with other ecosystems, etc. The goal is to build an environment where it's easy for our maintainers to keep things small over time, it's not just a one-off effort. Please see the Action Plan [3] for more details.
Want to become a member? Let me know!
Cheers! Adam
[1] https://docs.fedoraproject.org/en-US/minimization/ [2] https://docs.fedoraproject.org/en-US/minimization/team/ [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
I'm interested, but not just for minimization for the sake of it. We need to be thoughtful about how we are changing the dependency tree.
I would be especially interested in minimizing container images. I'd like to e.g. see purpose-built containers without an actual package manager inside. You just have the container, mount the config, and go. We're also trying to minimize Fedora CoreOS[1], so this is definitely a topic of overall interest!
[1] https://github.com/coreos/fedora-coreos-tracker/issues/186
Christian Glombek
Associate Software Engineer
Red Hat GmbH https://www.redhat.com/ https://www.google.com/maps/place/Engeldamm+64b,+10179+Berlin/@52.5058176,13.4191433,17z/data=!3m1!4b1!4m5!3m4!1s0x47a84e30d99f7f43:0xe6059fb480bfd85c!8m2!3d52.5058176!4d13.421332
cglombek@redhat.com akollmer@redhat.com https://red.ht/sig
Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn, Handelsregister: Amtsgericht München, HRB 153243, Geschäftsführer: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander
On Tue, Jul 30, 2019 at 5:24 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Jul 30, 2019 at 10:58 AM Adam Samalik asamalik@redhat.com wrote:
Hi everyone!
I'm starting a Minimization Objective [1] focusing on minimising the
installation size of some of the popular apps, runtimes, and other pieces of software in Fedora.
And there is a new Minimization Team [2] forming. Members of the team
will consult and work with Fedora maintainers, develop tooling and services, generate reports showing the status of the Fedora ecosystem and a comparison with other ecosystems, etc. The goal is to build an environment where it's easy for our maintainers to keep things small over time, it's not just a one-off effort. Please see the Action Plan [3] for more details.
Want to become a member? Let me know!
Cheers! Adam
[1] https://docs.fedoraproject.org/en-US/minimization/ [2] https://docs.fedoraproject.org/en-US/minimization/team/ [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
I'm interested, but not just for minimization for the sake of it. We need to be thoughtful about how we are changing the dependency tree.
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
If you want small images, just use buildah.
ctr=$(buildah from scratch) mnt=$(buildah mount $ctr) COPY/DnF/make install into $mnt buildah config ... $ctr buildah commit $ctr NEWIMAGE buildah push NEWIMAGE CONTAINERREGGISTY...
If you want to build off of base images, you can probably create them with buildah also.
On 7/30/19 12:05 PM, Christian Glombek wrote:
I would be especially interested in minimizing container images. I'd like to e.g. see purpose-built containers without an actual package manager inside. You just have the container, mount the config, and go. We're also trying to minimize Fedora CoreOS[1], so this is definitely a topic of overall interest!
[1] https://github.com/coreos/fedora-coreos-tracker/issues/186
Christian Glombek
Associate Software Engineer
Red Hat GmbH https://www.redhat.com/
cglombek@redhat.com mailto:akollmer@redhat.com
Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn, Handelsregister: Amtsgericht München, HRB 153243, Geschäftsführer: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander
On Tue, Jul 30, 2019 at 5:24 PM Neal Gompa <ngompa13@gmail.com mailto:ngompa13@gmail.com> wrote:
On Tue, Jul 30, 2019 at 10:58 AM Adam Samalik <asamalik@redhat.com <mailto:asamalik@redhat.com>> wrote: > > Hi everyone! > > I'm starting a Minimization Objective [1] focusing on minimising the installation size of some of the popular apps, runtimes, and other pieces of software in Fedora. > > And there is a new Minimization Team [2] forming. Members of the team will consult and work with Fedora maintainers, develop tooling and services, generate reports showing the status of the Fedora ecosystem and a comparison with other ecosystems, etc. The goal is to build an environment where it's easy for our maintainers to keep things small over time, it's not just a one-off effort. Please see the Action Plan [3] for more details. > > Want to become a member? Let me know! > > Cheers! > Adam > > [1] https://docs.fedoraproject.org/en-US/minimization/ > [2] https://docs.fedoraproject.org/en-US/minimization/team/ > [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/ > I'm interested, but not just for minimization for the sake of it. We need to be thoughtful about how we are changing the dependency tree. -- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org <mailto:devel@lists.fedoraproject.org> To unsubscribe send an email to devel-leave@lists.fedoraproject.org <mailto:devel-leave@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
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
I essentially want what Daniel suggested, as automatable infrastructure.
(There is is larger idea of having images without systemd as well; most some-kind-of-server rpms that I consider applicable here would have to be changed a little, too, as they all pull in systemd: e.g. %systemd_ordering instead of %systemd_requires and ensuring that tmpfiles,users, etc are created in the container as well (anything encoded in systemd unit files essentially).)
Christian Glombek
Associate Software Engineer
Red Hat GmbH https://www.redhat.com/ https://www.google.com/maps/place/Engeldamm+64b,+10179+Berlin/@52.5058176,13.4191433,17z/data=!3m1!4b1!4m5!3m4!1s0x47a84e30d99f7f43:0xe6059fb480bfd85c!8m2!3d52.5058176!4d13.421332
cglombek@redhat.com akollmer@redhat.com https://red.ht/sig
Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn, Handelsregister: Amtsgericht München, HRB 153243, Geschäftsführer: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander
On Tue, Jul 30, 2019 at 9:52 PM Daniel Walsh dwalsh@redhat.com wrote:
If you want small images, just use buildah.
ctr=$(buildah from scratch) mnt=$(buildah mount $ctr) COPY/DnF/make install into $mnt buildah config ... $ctr buildah commit $ctr NEWIMAGE buildah push NEWIMAGE CONTAINERREGGISTY...
If you want to build off of base images, you can probably create them with buildah also.
On 7/30/19 12:05 PM, Christian Glombek wrote:
I would be especially interested in minimizing container images. I'd like to e.g. see purpose-built containers without an actual package manager inside. You just have the container, mount the config, and go. We're also trying to minimize Fedora CoreOS[1], so this is definitely a topic of overall interest!
[1] https://github.com/coreos/fedora-coreos-tracker/issues/186
Christian Glombek
Associate Software Engineer
Red Hat GmbH https://www.redhat.com/
cglombek@redhat.com akollmer@redhat.com https://red.ht/sig
Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn, Handelsregister: Amtsgericht München, HRB 153243, Geschäftsführer: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander
On Tue, Jul 30, 2019 at 5:24 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Jul 30, 2019 at 10:58 AM Adam Samalik asamalik@redhat.com wrote:
Hi everyone!
I'm starting a Minimization Objective [1] focusing on minimising the
installation size of some of the popular apps, runtimes, and other pieces of software in Fedora.
And there is a new Minimization Team [2] forming. Members of the team
will consult and work with Fedora maintainers, develop tooling and services, generate reports showing the status of the Fedora ecosystem and a comparison with other ecosystems, etc. The goal is to build an environment where it's easy for our maintainers to keep things small over time, it's not just a one-off effort. Please see the Action Plan [3] for more details.
Want to become a member? Let me know!
Cheers! Adam
[1] https://docs.fedoraproject.org/en-US/minimization/ [2] https://docs.fedoraproject.org/en-US/minimization/team/ [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
I'm interested, but not just for minimization for the sake of it. We need to be thoughtful about how we are changing the dependency tree.
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
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].)
So that might be one area to focus on — to make sure that these "from scratch" installations don't drag unnecessary stuff.
[1] https://asamalik.fedorapeople.org/container-randomness/report.html [2] https://github.com/asamalik/container-randomness
On Tue, Jul 30, 2019 at 9:52 PM Daniel Walsh dwalsh@redhat.com wrote:
If you want small images, just use buildah.
ctr=$(buildah from scratch) mnt=$(buildah mount $ctr) COPY/DnF/make install into $mnt buildah config ... $ctr buildah commit $ctr NEWIMAGE buildah push NEWIMAGE CONTAINERREGGISTY...
If you want to build off of base images, you can probably create them with buildah also.
On 7/30/19 12:05 PM, Christian Glombek wrote:
I would be especially interested in minimizing container images. I'd like to e.g. see purpose-built containers without an actual package manager inside. You just have the container, mount the config, and go. We're also trying to minimize Fedora CoreOS[1], so this is definitely a topic of overall interest!
[1] https://github.com/coreos/fedora-coreos-tracker/issues/186
Christian Glombek
Associate Software Engineer
Red Hat GmbH https://www.redhat.com/
cglombek@redhat.com akollmer@redhat.com https://red.ht/sig
Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn, Handelsregister: Amtsgericht München, HRB 153243, Geschäftsführer: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander
On Tue, Jul 30, 2019 at 5:24 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Jul 30, 2019 at 10:58 AM Adam Samalik asamalik@redhat.com wrote:
Hi everyone!
I'm starting a Minimization Objective [1] focusing on minimising the
installation size of some of the popular apps, runtimes, and other pieces of software in Fedora.
And there is a new Minimization Team [2] forming. Members of the team
will consult and work with Fedora maintainers, develop tooling and services, generate reports showing the status of the Fedora ecosystem and a comparison with other ecosystems, etc. The goal is to build an environment where it's easy for our maintainers to keep things small over time, it's not just a one-off effort. Please see the Action Plan [3] for more details.
Want to become a member? Let me know!
Cheers! Adam
[1] https://docs.fedoraproject.org/en-US/minimization/ [2] https://docs.fedoraproject.org/en-US/minimization/team/ [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
I'm interested, but not just for minimization for the sake of it. We need to be thoughtful about how we are changing the dependency tree.
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
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.
Zbyszek
On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek zbyszek@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 :-).
Zbyszek
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Sat, Aug 3, 2019 at 11:24 PM Clement Verna cverna@fedoraproject.org wrote:
On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek zbyszek@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!
Zbyszek
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek zbyszek@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.
On Sun, 4 Aug 2019 at 18:17, Peter Robinson pbrobinson@gmail.com wrote:
On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek zbyszek@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 :-)
[0] - https://src.fedoraproject.org/container/tools/pull-request/6 [1] - https://pagure.io/fedora-ci/general/issue/47 [2] - https://github.com/docker-library/official-images/pull/6394#issuecomment-517... [3] - https://github.com/docker-library/official-images/pull/6394#issuecomment-517... [4] - https://github.com/coreos/clair
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On ma, 05 elo 2019, Clement Verna wrote:
On Sun, 4 Aug 2019 at 18:17, Peter Robinson pbrobinson@gmail.com wrote:
On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek zbyszek@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.
On Mon, 5 Aug 2019 at 10:59, Alexander Bokovoy abokovoy@redhat.com wrote:
On ma, 05 elo 2019, Clement Verna wrote:
On Sun, 4 Aug 2019 at 18:17, Peter Robinson pbrobinson@gmail.com wrote:
On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek zbyszek@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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Sun, 2019-08-04 at 16:18 +0100, Peter Robinson wrote:
On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek zbyszek@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 think such CI runs would be very useful even for other "classical" deliverables.
If the live image/netinst image/DVD image/installation initrd/etc. suddenly grows in size by say 20+ %, this is something that should trigger warnings & should be investigated.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Tue, Aug 6, 2019 at 1:34 PM Martin Kolman mkolman@redhat.com wrote:
On Sun, 2019-08-04 at 16:18 +0100, Peter Robinson wrote:
On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek zbyszek@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 think such CI runs would be very useful even for other "classical" deliverables.
If the live image/netinst image/DVD image/installation initrd/etc. suddenly grows in size by say 20+ %, this is something that should trigger warnings & should be investigated.
Yes, I think that could definitely be done!
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Whoop this is great! But I wonder why the scratch build sizes have gone up this dramatically in f31?
On Sun, Aug 4, 2019 at 10:59 AM Adam Samalik asamalik@redhat.com wrote:
On Sat, Aug 3, 2019 at 11:24 PM Clement Verna cverna@fedoraproject.org wrote:
On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek zbyszek@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!
Zbyszek
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
--
Adam Šamalík
Senior Software Engineer Red Hat _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Sun, Aug 04, 2019 at 05:27:21PM +0200, Christian Glombek wrote:
Whoop this is great! But I wonder why the scratch build sizes have gone up this dramatically in f31?
Also, there are still some obvious packages to trim:
No udev, but device-mapper, device-mapper-libs, which are not useful without udev.
Also, there's a bunch of -devel packages? What pulls those in? libmount-devel, libblkid-devel, glib2-devel, libassuan, libgpg-error-devel, libselinux-devel, libsepol-devel, pcre-devel, pcre2-devel, zlib-devel.
Zbyszek
On Mon, Aug 5, 2019 at 1:30 PM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
On Sun, Aug 04, 2019 at 05:27:21PM +0200, Christian Glombek wrote:
Whoop this is great! But I wonder why the scratch build sizes have gone up this dramatically
in
f31?
Also, there are still some obvious packages to trim:
No udev, but device-mapper, device-mapper-libs, which are not useful without udev.
Also, there's a bunch of -devel packages? What pulls those in? libmount-devel, libblkid-devel, glib2-devel, libassuan, libgpg-error-devel, libselinux-devel, libsepol-devel, pcre-devel, pcre2-devel, zlib-devel.
Looks like gpme pulls in glib2-devel which in turn pulls in other -devel packages. https://asamalik.fedorapeople.org/fedora-31-base.svg
Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
This has been fixed almost a week ago..
On Wed, Aug 7, 2019, 11:58 Adam Samalik asamalik@redhat.com wrote:
On Mon, Aug 5, 2019 at 1:30 PM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
On Sun, Aug 04, 2019 at 05:27:21PM +0200, Christian Glombek wrote:
Whoop this is great! But I wonder why the scratch build sizes have gone up this dramatically
in
f31?
Also, there are still some obvious packages to trim:
No udev, but device-mapper, device-mapper-libs, which are not useful without udev.
Also, there's a bunch of -devel packages? What pulls those in? libmount-devel, libblkid-devel, glib2-devel, libassuan, libgpg-error-devel, libselinux-devel, libsepol-devel, pcre-devel, pcre2-devel, zlib-devel.
Looks like gpme pulls in glib2-devel which in turn pulls in other -devel packages. https://asamalik.fedorapeople.org/fedora-31-base.svg
Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
--
Adam Šamalík
Senior Software Engineer Red Hat _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Wednesday, August 7, 2019, Igor Gnatenko < ignatenkobrain@fedoraproject.org> wrote:
This has been fixed almost a week ago..
Yeah, looking at the container image that's been released doesn't give us freshest data...
I guess if we generate reports in reaction to Koji builds for example, consuming content that's not been released yet (part of CI?), that would give us much more useful data.
On Wed, Aug 7, 2019, 11:58 Adam Samalik asamalik@redhat.com wrote:
On Mon, Aug 5, 2019 at 1:30 PM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
On Sun, Aug 04, 2019 at 05:27:21PM +0200, Christian Glombek wrote:
Whoop this is great! But I wonder why the scratch build sizes have gone up this
dramatically in
f31?
Also, there are still some obvious packages to trim:
No udev, but device-mapper, device-mapper-libs, which are not useful without udev.
Also, there's a bunch of -devel packages? What pulls those in? libmount-devel, libblkid-devel, glib2-devel, libassuan, libgpg-error-devel, libselinux-devel, libsepol-devel, pcre-devel, pcre2-devel, zlib-devel.
Looks like gpme pulls in glib2-devel which in turn pulls in other -devel packages. https://asamalik.fedorapeople.org/fedora-31-base.svg
Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
--
Adam Šamalík
Senior Software Engineer Red Hat _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Wed, 7 Aug 2019, 10:51 Adam Samalik, asamalik@redhat.com wrote:
On Mon, Aug 5, 2019 at 1:30 PM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
On Sun, Aug 04, 2019 at 05:27:21PM +0200, Christian Glombek wrote:
Whoop this is great! But I wonder why the scratch build sizes have gone up this dramatically
in
f31?
Also, there are still some obvious packages to trim:
No udev, but device-mapper, device-mapper-libs, which are not useful without udev.
Also, there's a bunch of -devel packages? What pulls those in? libmount-devel, libblkid-devel, glib2-devel, libassuan, libgpg-error-devel, libselinux-devel, libsepol-devel, pcre-devel, pcre2-devel, zlib-devel.
Looks like gpme pulls in glib2-devel which in turn pulls in other -devel packages. https://asamalik.fedorapeople.org/fedora-31-base.svg
Already fixed
Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
--
Adam Šamalík
Senior Software Engineer Red Hat _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
I'm on vacation and a few days behind on email, sorry.
"ZJ" == Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl writes:
ZJ> Also, there are still some obvious packages to trim:
I wonder if the rpm dependency on curl (the executable, not the library) is strictly necessary. I believe it's only because of the %__urlhelpercmd macro. Are rpm remote file operations considered to be mandatory functionality?
It would be nice if we could get by without requiring openldap and krb5-libs but I suspect we'd have to be Gentoo to reach that level of minimization.
It would also be nice to see libdb excised, but it's still a core requirement for rpm. The only other things that need it are cyrus-sasl and pam, both of which would do without it with some additional subpackage splitting, I think.
It's interesting that gawk is only there because of krb5-libs, but I don't see why. Nothing in that package seems to call awk. That's about 3.5MB.
Is tar considered mandatory? Nothing appears to depend on it, and its 3MB....
ZJ> Also, there's a bunch of -devel packages? What pulls those in? ZJ> libmount-devel, libblkid-devel, glib2-devel, libassuan, ZJ> libgpg-error-devel, libselinux-devel, libsepol-devel, pcre-devel, ZJ> pcre2-devel, zlib-devel.
Seems that's already been fixed.
- J<
On Wed, Aug 7, 2019 at 1:17 PM Jason Tibbitts tibbs@math.uh.edu wrote:
I'm on vacation and a few days behind on email, sorry.
"ZJ" == Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl writes:
ZJ> Also, there are still some obvious packages to trim:
I wonder if the rpm dependency on curl (the executable, not the library) is strictly necessary. I believe it's only because of the %__urlhelpercmd macro. Are rpm remote file operations considered to be mandatory functionality?
https://src.fedoraproject.org/rpms/rpm/pull-request/12
It would be nice if we could get by without requiring openldap and krb5-libs but I suspect we'd have to be Gentoo to reach that level of minimization.
We can actually get rid out of this using `libcurl-minimal`, but it is not easy to teach DNF to replace libcurl-minimal with libcurl without explicit --allowerasing on the command line.
It would also be nice to see libdb excised, but it's still a core requirement for rpm. The only other things that need it are cyrus-sasl and pam, both of which would do without it with some additional subpackage splitting, I think.
It's interesting that gawk is only there because of krb5-libs, but I don't see why. Nothing in that package seems to call awk. That's about 3.5MB.
It seems that it used to be Requires(triggerun), then for some reason it was moved into Requires. I don't see any reason why it would be needed for krb5-libs from the first try.
Is tar considered mandatory? Nothing appears to depend on it, and its 3MB....
ZJ> Also, there's a bunch of -devel packages? What pulls those in? ZJ> libmount-devel, libblkid-devel, glib2-devel, libassuan, ZJ> libgpg-error-devel, libselinux-devel, libsepol-devel, pcre-devel, ZJ> pcre2-devel, zlib-devel.
Seems that's already been fixed.
- J<
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
"IG" == Igor Gnatenko ignatenkobrain@fedoraproject.org writes:
IG> We can actually get rid out of this using `libcurl-minimal`, but it IG> is not easy to teach DNF to replace libcurl-minimal with libcurl IG> without explicit --allowerasing on the command line.
That does prompt the question as to whether dnf itself is required for "minimal" functionality. If I'm composing my own container image I might not really need dnf (or even rpm, really). Instead of updating I'd just compose a fresh image.
The question of whether tar is required should be easier. And of the 3MB of installed size of the tar package, not even 500k is the tar binary; the rest is localizations and docs. So the question really does come down to just how small of an image is actually desired, and how much packaging work is needed to get there.
Which prompts another question: Are the packages in these images installed without docs?
IG> It seems that it used to be Requires(triggerun), then for some IG> reason it was moved into Requires. I don't see any reason why it IG> would be needed for krb5-libs from the first try.
Here's the scriptlet:
%triggerun libs -- krb5-libs < 1.15.1-5 if ! grep -q 'includedir /etc/krb5.conf.d' /etc/krb5.conf ; then sed -i '1i # To opt out of the system crypto-policies configuration of krb5, remove the\n# symlink at /etc/krb5.conf.d/crypto-policies which will not be recreated.\nincludedir /etc/krb5.conf.d/\n' /etc/krb5.conf fi exit 0
So... there's not actually a call to awk. And the last version of Fedora to have anything older than 1.15.1 was F28. We don't supports updates from F28 to F31 (and certainly not updates from F28 when it was rawhide), so the scriptlet is no longer necessary at all. It has come and gone a few times throughout history but the dependency has remained.
- J<
Here's the scriptlet:
%triggerun libs -- krb5-libs < 1.15.1-5 if ! grep -q 'includedir /etc/krb5.conf.d' /etc/krb5.conf ; then sed -i '1i # To opt out of the system crypto-policies configuration of krb5, remove the\n# symlink at /etc/krb5.conf.d/crypto-policies which will not be recreated.\nincludedir /etc/krb5.conf.d/\n' /etc/krb5.conf fi exit 0
So... there's not actually a call to awk. And the last version of Fedora to have anything older than 1.15.1 was F28.
Please CC maintainers when discussing their package. We like it because it avoids us getting blindsided by requirements/changes, and sometimes we know things about our packages and can be helpful :)
There are two uses of awk: one at build-time, and one for the triggers. I assume no one cares that I need awk to build. You're correct that the use for the triggers can probably go away since they're aren't any right now, but... does this actually matter? Please file a bugzilla if so.
We don't supports updates from F28 to F31 (and certainly not updates from F28 when it was rawhide), so the scriptlet is no longer necessary at all. It has come and gone a few times throughout history but the dependency has remained.
Just because something /can/ go doesn't mean it /should/. A trigger that doesn't fire won't hurt anything, and its removal is more noise to filter through. And there are often other considerations: for instance, the el8 spec file is branched from the Fedora one - el7 has a 1.15-series krb5. The upgrade window I have to support is larger than what's mandated by Fedora - and that's fine! It's not causing any problems for other things, so it doesn't matter to anyone but me.
Thanks, --Robbie
On Wed, Aug 14, 2019 at 8:49 PM Robbie Harwood rharwood@redhat.com wrote:
Here's the scriptlet:
%triggerun libs -- krb5-libs < 1.15.1-5 if ! grep -q 'includedir /etc/krb5.conf.d' /etc/krb5.conf ; then sed -i '1i # To opt out of the system crypto-policies configuration of krb5, remove the\n# symlink at /etc/krb5.conf.d/crypto-policies which will not be recreated.\nincludedir /etc/krb5.conf.d/\n' /etc/krb5.conf fi exit 0
So... there's not actually a call to awk. And the last version of Fedora to have anything older than 1.15.1 was F28.
Please CC maintainers when discussing their package. We like it because it avoids us getting blindsided by requirements/changes, and sometimes we know things about our packages and can be helpful :)
Absolutely we need to engage with maintainers when debating changes. Doing this in isolation would basically mean failure.
There are two uses of awk: one at build-time, and one for the triggers. I assume no one cares that I need awk to build. You're correct that the use for the triggers can probably go away since they're aren't any right now, but... does this actually matter? Please file a bugzilla if so.
We don't supports updates from F28 to F31 (and certainly not updates from F28 when it was rawhide), so the scriptlet is no longer necessary at all. It has come and gone a few times throughout history but the dependency has remained.
Just because something /can/ go doesn't mean it /should/.
Yep!
A trigger that doesn't fire won't hurt anything, and its removal is more noise to filter through. And there are often other considerations: for instance, the el8 spec file is branched from the Fedora one - el7 has a 1.15-series krb5. The upgrade window I have to support is larger than what's mandated by Fedora - and that's fine! It's not causing any problems for other things, so it doesn't matter to anyone but me.
Thanks, --Robbie _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Tue, Jul 30, 2019, at 3:52 PM, Daniel Walsh wrote:
If you want small images, just use buildah.
Dockerfile-based multi-stage builds are significantly more popular than this and should really be mentioned first.
I'm not saying `buildah` is bad, but...what you're talking about here also encourages using the host as a build root which has various negatives.
And I think the main conversation to have is whether we should introduce something more like https://github.com/GoogleContainerTools/distroless that basically just has:
- glibc - ca-certificates
Or to rephrase, a sufficient runtime for e.g. a Rust/golang binary and that's it. (While people often say both Rust and golang are statically linked, that's true of the language code, but by default Rust links to glibc, Go does not, and I think what Rust does is better and should be encouraged, so we want a libc in this "ultramin" container)
On Wed, Aug 7, 2019, at 11:25 AM, Colin Walters wrote:
On Tue, Jul 30, 2019, at 3:52 PM, Daniel Walsh wrote:
If you want small images, just use buildah.
Dockerfile-based multi-stage builds are significantly more popular than this and should really be mentioned first.
I'm not saying `buildah` is bad, but...what you're talking about here also encourages using the host as a build root which has various negatives.
And I think the main conversation to have is whether we should introduce something more like https://github.com/GoogleContainerTools/distroless that basically just has:
- glibc
- ca-certificates
And an interesting discussion here is whether to include e.g. openssl. golang by default uses custom (statically linked) crypto but it can be configured to use openssl. Rust doesn't have a default but...openssl is at least a common option.
On 8/7/19 11:24 AM, Colin Walters wrote:
On Tue, Jul 30, 2019, at 3:52 PM, Daniel Walsh wrote:
If you want small images, just use buildah.
Dockerfile-based multi-stage builds are significantly more popular than this and should really be mentioned first.
Buildah supports multi-stage builds as well.
I'm not saying `buildah` is bad, but...what you're talking about here also encourages using the host as a build root which has various negatives.
And I think the main conversation to have is whether we should introduce something more like https://github.com/GoogleContainerTools/distroless that basically just has:
- glibc
- ca-certificates
Or to rephrase, a sufficient runtime for e.g. a Rust/golang binary and that's it. (While people often say both Rust and golang are statically linked, that's true of the language code, but by default Rust links to glibc, Go does not, and I think what Rust does is better and should be encouraged, so we want a libc in this "ultramin" container) _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Wed, Aug 7, 2019 at 5:26 PM Colin Walters walters@verbum.org wrote:
On Tue, Jul 30, 2019, at 3:52 PM, Daniel Walsh wrote:
If you want small images, just use buildah.
Dockerfile-based multi-stage builds are significantly more popular than this and should really be mentioned first.
I'm not saying `buildah` is bad, but...what you're talking about here also encourages using the host as a build root which has various negatives.
And I think the main conversation to have is whether we should introduce something more like https://github.com/GoogleContainerTools/distroless that basically just has:
- glibc
- ca-certificates
Or to rephrase, a sufficient runtime for e.g. a Rust/golang binary and
that's it. (While people often say both Rust and golang are statically linked, that's true of the language code, but by default Rust links to glibc, Go does not, and I think what Rust does is better and should be encouraged, so we want a libc in this "ultramin" container)
Wow, a model like _distroless_ is exactly what I think we need in and from Fedora to enable making those minimal, purpose-built and service-specific containers.
I was thinking of a concept that has rpm-ostree compose a set of packages to a root dir, and put that in a container with Buildah. Not sure how feasible it would be to add that functionality (as opposed to simply using dnf for this), but I'm thinking it would be super neat to have a coreos-assembler that also does container composes from an ostree manifest, in the same way it assembles OS images in different formats for different platforms.
I'd also like to link to Adam's super informational page here: https://asamalik.fedorapeople.org/container-randomness/report-f31.html It would be great if we could include infos about the package sets of our ostree-based composes in there as well (FCOS, Silverblue and IoT). Also note that our container scratch build size has gone up dramatically in F31 (I don't know why, yet).
cc'ing Ben Breard and Sanja Bonic for their general interest in the Minimization effort.
On Monday, August 26, 2019 5:50:53 AM MST Christian Glombek wrote:
On Wed, Aug 7, 2019 at 5:26 PM Colin Walters walters@verbum.org wrote:
On Tue, Jul 30, 2019, at 3:52 PM, Daniel Walsh wrote:
If you want small images, just use buildah.
Dockerfile-based multi-stage builds are significantly more popular than this and should really be mentioned first.
I'm not saying `buildah` is bad, but...what you're talking about here also encourages using the host as a build root which has various negatives.
And I think the main conversation to have is whether we should introduce something more like https://github.com/GoogleContainerTools/distroless
that basically just has:
- glibc
- ca-certificates
Or to rephrase, a sufficient runtime for e.g. a Rust/golang binary and
that's it. (While people often say both Rust and golang are statically linked, that's true
of the language code, but by default Rust links to glibc, Go does not,
and I
think what Rust does is better and should be encouraged, so we want a libc in this "ultramin" container)
Wow, a model like _distroless_ is exactly what I think we need in and from Fedora to enable making those minimal, purpose-built and service-specific containers.
I was thinking of a concept that has rpm-ostree compose a set of packages to a root dir, and put that in a container with Buildah. Not sure how feasible it would be to add that functionality (as opposed to simply using dnf for this), but I'm thinking it would be super neat to have a coreos-assembler that also does container composes from an ostree manifest, in the same way it assembles OS images in different formats for different platforms.
I'd also like to link to Adam's super informational page here: https://asamalik.fedorapeople.org/container-randomness/report-f31.html It would be great if we could include infos about the package sets of our ostree-based composes in there as well (FCOS, Silverblue and IoT). Also note that our container scratch build size has gone up dramatically in F31 (I don't know why, yet).
cc'ing Ben Breard and Sanja Bonic for their general interest in the Minimization effort.
That sort of container is exactly the kind of thing that *cannot be maintained*. I say this as a sysadmin in a fairly large environment, that container simply *would not get updated*. It'd sit until it either quit working or somebody noticed it and removed it because it was a security risk, full of vulnerabilities.
On Mon, Aug 26, 2019 at 06:46:29PM -0700, John Harris wrote:
On Monday, August 26, 2019 5:50:53 AM MST Christian Glombek wrote:
Wow, a model like _distroless_ is exactly what I think we need in and from Fedora to enable making those minimal, purpose-built and service-specific containers.
I was thinking of a concept that has rpm-ostree compose a set of packages to a root dir, and put that in a container with Buildah. Not sure how feasible it would be to add that functionality (as opposed to simply using dnf for this), but I'm thinking it would be super neat to have a coreos-assembler that also does container composes from an ostree manifest, in the same way it assembles OS images in different formats for different platforms.
I'd also like to link to Adam's super informational page here: https://asamalik.fedorapeople.org/container-randomness/report-f31.html It would be great if we could include infos about the package sets of our ostree-based composes in there as well (FCOS, Silverblue and IoT). Also note that our container scratch build size has gone up dramatically in F31 (I don't know why, yet).
cc'ing Ben Breard and Sanja Bonic for their general interest in the Minimization effort.
That sort of container is exactly the kind of thing that *cannot be maintained*. I say this as a sysadmin in a fairly large environment, that container simply *would not get updated*. It'd sit until it either quit working or somebody noticed it and removed it because it was a security risk, full of vulnerabilities.
John, if you do not want to use the containers, then don't do it. There are people who like containers and are serious about them. Being serious means that one has automated pipeline that builds, tests and deploys updated container, without engaging sysadmins.
Your remarks do not move discussion forward. The point is how to get smallest viable container. Your comments ignore decades of experience of containerising workloads.
On Monday, August 26, 2019 9:16:30 PM MST Tomasz Torcz wrote:
On Mon, Aug 26, 2019 at 06:46:29PM -0700, John Harris wrote:
On Monday, August 26, 2019 5:50:53 AM MST Christian Glombek wrote:
Wow, a model like _distroless_ is exactly what I think we need in and from Fedora to enable making those minimal, purpose-built and service-specific containers.
I was thinking of a concept that has rpm-ostree compose a set of packages to a root dir, and put that in a container with Buildah. Not sure how feasible it would be to add that functionality (as opposed to simply using dnf for this), but I'm thinking it would be super neat to have a coreos-assembler that also does container composes from an ostree manifest, in the same way it assembles OS images in different formats for different platforms.
I'd also like to link to Adam's super informational page here: https://asamalik.fedorapeople.org/container-randomness/report-f31.html It would be great if we could include infos about the package sets of our ostree-based composes in there as well (FCOS, Silverblue and IoT). Also note that our container scratch build size has gone up dramatically in F31 (I don't know why, yet).
cc'ing Ben Breard and Sanja Bonic for their general interest in the Minimization effort.
That sort of container is exactly the kind of thing that *cannot be maintained*. I say this as a sysadmin in a fairly large environment, that
container simply *would not get updated*. It'd sit until it either quit working or somebody noticed it and removed it because it was a security risk, full of vulnerabilities.
John, if you do not want to use the containers, then don't do it. There are people who like containers and are serious about them. Being serious means that one has automated pipeline that builds, tests and deploys updated container, without engaging sysadmins.
Your remarks do not move discussion forward. The point is how to get smallest viable container. Your comments ignore decades of experience of containerising workloads.
-- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz .. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
I'm not saying not to use containers. There is a right way to do it, and a wrong way to do it. A container should be as the name describes, a containerized installation of the distro in question, with the utilities needed to support a given role. Not something that never gets updated, never gets security fixes. Deploying new GNU/Linux based systems without engaging a sysadmin or the sysadmin team sounds like a recipe for disaster.
I disagree, and I find your remarks to be quite hostile. The smallest viable container can exist without getting rid of required utilities, such as the package manager.
On Monday, August 26, 2019 9:39:47 PM MST John Harris wrote:
On Monday, August 26, 2019 9:16:30 PM MST Tomasz Torcz wrote:
On Mon, Aug 26, 2019 at 06:46:29PM -0700, John Harris wrote:
On Monday, August 26, 2019 5:50:53 AM MST Christian Glombek wrote:
Wow, a model like _distroless_ is exactly what I think we need in and from Fedora to enable making those minimal, purpose-built and service-specific containers.
I was thinking of a concept that has rpm-ostree compose a set of packages to a root dir, and put that in a container with Buildah. Not sure how feasible it would be to add that functionality (as opposed to simply using dnf for this), but I'm thinking it would be super neat to have a coreos-assembler that also does container composes from an ostree manifest, in the same way it assembles OS images in different formats for different platforms.
I'd also like to link to Adam's super informational page here: https://asamalik.fedorapeople.org/container-randomness/report-f31.html
It would be great if we could include infos about the package sets of our ostree-based composes in there as well (FCOS, Silverblue and IoT). Also note that our container scratch build size has gone up dramatically in F31 (I don't know why, yet).
cc'ing Ben Breard and Sanja Bonic for their general interest in the Minimization effort.
That sort of container is exactly the kind of thing that *cannot be maintained*. I say this as a sysadmin in a fairly large environment, that
container simply *would not get updated*. It'd sit until it either quit
working or somebody noticed it and removed it because it was a security risk, full of vulnerabilities.
John, if you do not want to use the containers, then don't do it.
There are people who like containers and are serious about them. Being serious means that one has automated pipeline that builds, tests and deploys updated container, without engaging sysadmins.
Your remarks do not move discussion forward. The point is how to get
smallest viable container. Your comments ignore decades of experience of containerising workloads.
-- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz .. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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.or g
I'm not saying not to use containers. There is a right way to do it, and a wrong way to do it. A container should be as the name describes, a containerized installation of the distro in question, with the utilities needed to support a given role. Not something that never gets updated, never gets security fixes. Deploying new GNU/Linux based systems without engaging a sysadmin or the sysadmin team sounds like a recipe for disaster.
I disagree, and I find your remarks to be quite hostile. The smallest viable
container can exist without getting rid of required utilities, such as
the package manager.
-- John M. Harris, Jr. johnmh@splentity.com Splentity https://splentity.com/
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
For an example of containers used properly, please see my 2016 Fedora Magazine article on systemd-nspawn: https://fedoramagazine.org/container-technologies-fedora-systemd-nspawn/
On 8/26/19 9:39 PM, John Harris wrote:
I'm not saying not to use containers. There is a right way to do it, and a wrong way to do it. A container should be as the name describes, a containerized installation of the distro in question, with the utilities needed to support a given role. Not something that never gets updated, never gets security fixes. Deploying new GNU/Linux based systems without engaging a sysadmin or the sysadmin team sounds like a recipe for disaster.
That may be your use case, but not the way others use them. You can still use containers how you want. But either do some research about how containers can be used in different ways or stop telling others that they're doing it wrong. A common use case is for containers to be throw away. If something needs updating, a new container is created and tested and then deployed replacing the existing one. No online updates.
I disagree, and I find your remarks to be quite hostile. The smallest viable container can exist without getting rid of required utilities, such as the package manager.
And you can still use it with the package manager if you want. But there are completely valid use cases that don't have any use for the package manager and want the smallest container possible. There was nothing hostile about the replies to you. They are just telling you that your case is not the only one and to stop telling them that they are wrong.
On Monday, August 26, 2019 10:17:46 PM MST Samuel Sieb wrote:
On 8/26/19 9:39 PM, John Harris wrote:
I'm not saying not to use containers. There is a right way to do it, and a wrong way to do it. A container should be as the name describes, a containerized installation of the distro in question, with the utilities needed to support a given role. Not something that never gets updated, never
gets security fixes. Deploying new GNU/Linux based systems without
engaging a sysadmin or the sysadmin team sounds like a recipe for disaster.
That may be your use case, but not the way others use them. You can still use containers how you want. But either do some research about how containers can be used in different ways or stop telling others that they're doing it wrong. A common use case is for containers to be throw away. If something needs updating, a new container is created and tested and then deployed replacing the existing one. No online updates.
I disagree, and I find your remarks to be quite hostile. The smallest viable
container can exist without getting rid of required utilities,
such as the package manager.
And you can still use it with the package manager if you want. But there are completely valid use cases that don't have any use for the package manager and want the smallest container possible. There was nothing hostile about the replies to you. They are just telling you that your case is not the only one and to stop telling them that they are wrong. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
I'm not telling anyone they can't do anything. However, it's a very bad idea, and if it gets done that way, it's a security issue. It's one thing if it's spawned as needed, then deleted in a few minutes or hours, and another if it's just left installed as-is. No online updates is the exact issue I see with this. That's a security nightmare.
If you don't have a package manager there, it simply will not be updated. It'll be installed once, then either left there forever, un-updated, with tons of vulnerabilities piling up.
On Tue, Aug 27, 2019 at 01:22 John Harris wrote: [snip]
No online updates is the exact issue I see with this. That's a security nightmare.
If you don't have a package manager there, it simply will not be updated. It'll be installed once, then either left there forever, un-updated, with tons of vulnerabilities piling up.
IIUC the proposal from Christian to use rpm-ostree as a build stage to produce the runtime container, then you can still do online update, but instead of commiting the result of a dnf update, you commit a new rpm-ostree composed rootfs.
Regards, -Tristan
On Tue, Aug 27, 2019 at 2:09 PM Tristan Cacqueray tdecacqu@redhat.com wrote:
On Tue, Aug 27, 2019 at 01:22 John Harris wrote: [snip]
No online updates is the exact issue I see with this. That's a security
nightmare.
If you don't have a package manager there, it simply will not be
updated.
It'll be installed once, then either left there forever, un-updated,
with tons
of vulnerabilities piling up.
I see Kubernetes/OpenShift workloads as a very well suited use-case for purpose-built, minimal containers that do not require a package manager. There is a lot of tooling available right now to automate container builds, continuous testing and integration, e.g ImageStreams on OpenShift. In this model, changes to the container deployment are made by pushing a new immutable image and executing a custom fitted update strategie: staging, gradual updates, simultaneous versions, etc. No container needs to be mutated ever. New ones are spun up, traffic is rerouted, old ones are destroyed.
You have voiced your concern with this new proposed approach and it is indeed not fitted for the workflow you are describing, but please let us focus away from the status quo on to new ideas wrt the Minimization effort. Also I assure you, nobody is planning to take the standard Fedora dnf container away from you, or anybody.
IIUC the proposal from Christian to use rpm-ostree as a build stage to
produce the runtime container, then you can still do online update, but instead of commiting the result of a dnf update, you commit a new rpm-ostree composed rootfs.
Yes, exactly. Although the container build tooling/system and the container contents (i.e whether or not a package manager is included) are somewhat orthogonal here: Right now, one can do something like `dnf --installroot=/mnt/new-buildah-root group install custom-environment` to create a root for a container and installed group may include a package manager or not.
I am not aware of a way to do the equivalent with rpm-ostree, yet, and there are a lot of open questions I'd like to explore around that: - How would a runtime update of the rpm-ostree-in-container work? - Can we enable composing a dnf container with rpm-ostree (and the other way around, use dnf to create an rpm-ostree container root)
-Christian
Regards, -Tristan _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Tuesday, August 27, 2019 6:18:41 AM MST Christian Glombek wrote:
Right now, one can do something like `dnf --installroot=/mnt/new-buildah-root group install custom-environment` to create a root for a container and installed group may include a package manager or not.
This would install `rpm` and `dnf` at the very least, and would most likely pull in many other supporting packages, unless something has changed since the last release, like checking against the string "buildah" or something like that.
On Tue, Aug 27, 2019 at 3:27 PM John Harris johnmh@splentity.com wrote:
On Tuesday, August 27, 2019 6:18:41 AM MST Christian Glombek wrote:
Right now, one can do something like `dnf --installroot=/mnt/new-buildah-root group install custom-environment` to create a root for a container and installed group may include a
package
manager or not.
This would install `rpm` and `dnf` at the very least, and would most likely pull in many other supporting packages, unless something has changed since the last release, like checking against the string "buildah" or something like that.
That would really depend on the contents of that custom group, but you can install a set of packages that way as well, as you would usually. AIUI reducing the number of packages pulled in by dependency resolving is another one of the aims of this effort for Fedora packages.
On Tuesday, July 30, 2019 9:05:31 AM MST Christian Glombek wrote:
I would be especially interested in minimizing container images. I'd like to e.g. see purpose-built containers without an actual package manager inside. You just have the container, mount the config, and go. We're also trying to minimize Fedora CoreOS[1], so this is definitely a topic of overall interest!
[1] https://github.com/coreos/fedora-coreos-tracker/issues/186
Christian Glombek
Associate Software Engineer
Red Hat GmbH https://www.redhat.com/ https://www.google.com/maps/place/Engeldamm+64b,+10179+Berlin/@52.5058176,1 3.4191433,17z/data=!3m1!4b1!4m5!3m4!1s0x47a84e30d99f7f43:0xe6059fb480bfd85c! 8m2!3d52.5058176!4d13.421332
cglombek@redhat.com akollmer@redhat.com https://red.ht/sig
Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn, Handelsregister: Amtsgericht München, HRB 153243, Geschäftsführer: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander
On Tue, Jul 30, 2019 at 5:24 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Jul 30, 2019 at 10:58 AM Adam Samalik asamalik@redhat.com wrote:
Hi everyone!
I'm starting a Minimization Objective [1] focusing on minimising the
installation size of some of the popular apps, runtimes, and other pieces of software in Fedora.
And there is a new Minimization Team [2] forming. Members of the team
will consult and work with Fedora maintainers, develop tooling and services, generate reports showing the status of the Fedora ecosystem and a comparison with other ecosystems, etc. The goal is to build an environment where it's easy for our maintainers to keep things small over time, it's not just a one-off effort. Please see the Action Plan [3] for more details.
Want to become a member? Let me know!
Cheers! Adam
[1] https://docs.fedoraproject.org/en-US/minimization/ [2] https://docs.fedoraproject.org/en-US/minimization/team/ [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
I'm interested, but not just for minimization for the sake of it. We need to be thoughtful about how we are changing the dependency tree.
-- 真実はいつも一つ!/ Always, there's only one truth!
Having a container without a package manager sounds like the worst possible thing to add to an already poorly implemented solution. In reality, containers, regardless of what they're running, should be treated as what they are, GNU/Linux installs. Each one should be self sufficient from the host system, so that they can be properly updated using a package manager.
Each container should, realistically, be a self contained system.
On Tue, Aug 20, 2019 at 10:52:18PM -0700, John Harris wrote:
Having a container without a package manager sounds like the worst possible thing to add to an already poorly implemented solution. In reality, containers, regardless of what they're running, should be treated as what they are, GNU/Linux installs. Each one should be self sufficient from the host system, so that they can be properly updated using a package manager.
Each container should, realistically, be a self contained system.
You do not update the container. You rebuild it, creating new image with updated components, then you test&roll out new image. Package manager is only needed during the build (in fact, it is indispensable at this step) but not during runtime.
On 8/21/19 5:00 AM, Tomasz Torcz wrote:
On Tue, Aug 20, 2019 at 10:52:18PM -0700, John Harris wrote:
Having a container without a package manager sounds like the worst possible thing to add to an already poorly implemented solution. In reality, containers, regardless of what they're running, should be treated as what they are, GNU/Linux installs. Each one should be self sufficient from the host system, so that they can be properly updated using a package manager.
Each container should, realistically, be a self contained system.
You do not update the container. You rebuild it, creating new image with updated components, then you test&roll out new image. Package manager is only needed during the build (in fact, it is indispensable at this step) but not during runtime.
I agree. Entering a container and doing a yum update is an Anti-pattern. The way container images updates is envisioned is when I need an updated container, I pull down a brand new image. Hopefully this image has gone through a thorough CI/CD system. The container image on the build system probably is built using dnf/yum, but those tools do not necessarily need to be in the final image. Preferably they would not be there. Unfortunately in the real world this is not true. And the default Dockerfile construct enforces base layers to have dnf installed. Buildah and Multi-Stage builds do allow you to eliminate these tools, but that is more difficult to do.
On Wed, Aug 21, 2019, at 7:34 AM, Daniel Walsh wrote:
I agree. Entering a container and doing a yum update is an Anti-pattern.
This is a complex discussion - I think we need both. Personally I live inside a "pet" container using https://github.com/cgwalters/coretoolbox and I definitely `yum update` inside there, though I do also periodically destroy it and re-pull.
Kubernetes though for sure is about non-pet containers.
Buildah and Multi-Stage builds do allow you to eliminate these tools, but that is more difficult to do.
multi-stage is easy and obvious for the case of e.g. Golang and Rust single compiled binaries, and it's not too hard to do for other compiled languages (C/C++) as long as you have a notion of `BuildRequires` versus `Requires`. For interpreted languages though, yeah, not as worthwhile unless you're pulling in a *lot* of build dependencies (doc tooling?) distinct from your runtime ones.
On Wed, Aug 21, 2019 at 09:13 Colin Walters wrote:
On Wed, Aug 21, 2019, at 7:34 AM, Daniel Walsh wrote:
I agree. Entering a container and doing a yum update is an Anti-pattern.
This is a complex discussion - I think we need both. Personally I live inside a "pet" container using https://github.com/cgwalters/coretoolbox and I definitely `yum update` inside there, though I do also periodically destroy it and re-pull.
I also run yum to keep my local runtime updated and I even suggested a new buildah commit option to make this more efficient: https://github.com/containers/buildah/issues/1778
Though this is useful for devel or traditional workstation use-case. It seems like a fedora image should come with the package manager, but perhaps it should only be used as a build stage using an option similar to the --installroot option?
Regards, -Tristan
Kubernetes though for sure is about non-pet containers.
Buildah and Multi-Stage builds do allow you to eliminate these tools, but that is more difficult to do.
multi-stage is easy and obvious for the case of e.g. Golang and Rust single compiled binaries, and it's not too hard to do for other compiled languages (C/C++) as long as you have a notion of `BuildRequires` versus `Requires`. For interpreted languages though, yeah, not as worthwhile unless you're pulling in a *lot* of build dependencies (doc tooling?) distinct from your runtime ones. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Wednesday, August 21, 2019 2:00:07 AM MST Tomasz Torcz wrote:
On Tue, Aug 20, 2019 at 10:52:18PM -0700, John Harris wrote:
Having a container without a package manager sounds like the worst possible thing to add to an already poorly implemented solution. In reality, containers, regardless of what they're running, should be treated as what they are, GNU/Linux installs. Each one should be self sufficient from the host system, so that they can be properly updated using a package manager. Each container should, realistically, be a self contained system.
You do not update the container. You rebuild it, creating new image with updated components, then you test&roll out new image. Package manager is only needed during the build (in fact, it is indispensable at this step) but not during runtime.
-- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz .. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Why in the world would anyone do such a thing? That is impossible to maintain, and is a horrible security risk.
On Tue, Jul 30, 2019 at 7:58 AM Adam Samalik asamalik@redhat.com wrote:
Hi everyone!
I'm starting a Minimization Objective [1] focusing on minimising the installation size of some of the popular apps, runtimes, and other pieces of software in Fedora.
And there is a new Minimization Team [2] forming. Members of the team will consult and work with Fedora maintainers, develop tooling and services, generate reports showing the status of the Fedora ecosystem and a comparison with other ecosystems, etc. The goal is to build an environment where it's easy for our maintainers to keep things small over time, it's not just a one-off effort. Please see the Action Plan [3] for more details.
Want to become a member? Let me know!
Cheers! Adam
[1] https://docs.fedoraproject.org/en-US/minimization/ [2] https://docs.fedoraproject.org/en-US/minimization/team/ [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
Hi Adam, Please put me on the list of people who would like to be on the team. I'm not sure how Paul would feel about me working on the minimization efforts (I'm currently doing EPEL stuff), but I feel it would fit in with my RHEL9 and Fedora IoT efforts. Plus, I'm always trying to get installs and systems as small as possible. Troy Dawson
Count me in! I'm not sure if I will have much time to do actual work, but surely I can help people with advises :)
On Tue, Jul 30, 2019 at 4:58 PM Adam Samalik asamalik@redhat.com wrote:
Hi everyone!
I'm starting a Minimization Objective [1] focusing on minimising the installation size of some of the popular apps, runtimes, and other pieces of software in Fedora.
And there is a new Minimization Team [2] forming. Members of the team will consult and work with Fedora maintainers, develop tooling and services, generate reports showing the status of the Fedora ecosystem and a comparison with other ecosystems, etc. The goal is to build an environment where it's easy for our maintainers to keep things small over time, it's not just a one-off effort. Please see the Action Plan [3] for more details.
Want to become a member? Let me know!
Cheers! Adam
[1] https://docs.fedoraproject.org/en-US/minimization/ [2] https://docs.fedoraproject.org/en-US/minimization/team/ [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
--
Adam Šamalík
Senior Software Engineer Red Hat _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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-announce@lists.fedorapro...
Thanks all of you who want to join! Welcome!
I'll add you to the team page [1] and follow up with some organisational stuff — we might want a weekly meeting to sync, etc. I proposed some communication channels on the team page as well, let me know if that works for you.
Cheers! Adam
[1] https://docs.fedoraproject.org/en-US/minimization/team/
On Tue, Jul 30, 2019 at 3:20 PM Adam Samalik asamalik@redhat.com wrote:
Hi everyone!
I'm starting a Minimization Objective [1] focusing on minimising the installation size of some of the popular apps, runtimes, and other pieces of software in Fedora.
And there is a new Minimization Team [2] forming. Members of the team will consult and work with Fedora maintainers, develop tooling and services, generate reports showing the status of the Fedora ecosystem and a comparison with other ecosystems, etc. The goal is to build an environment where it's easy for our maintainers to keep things small over time, it's not just a one-off effort. Please see the Action Plan [3] for more details.
Want to become a member? Let me know!
Cheers! Adam
[1] https://docs.fedoraproject.org/en-US/minimization/ [2] https://docs.fedoraproject.org/en-US/minimization/team/ [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
--
Adam Šamalík
Senior Software Engineer Red Hat