This is a tracking bug for Change: Container Minimal Image For more details, see: https://fedoraproject.org//wiki/Changes/ContainerMinimalImage Produce a new container image that contains as little as possible, but also still provides the ability to install packages from dnf repositories.
On 2017-Feb-28, we have reached the Fedora 26 Change Checkpoint: Completion deadline (testable). At this point, all accepted changes should be substantially complete, and testable. Additionally, if a change is to be enabled by default, it must be enabled at Change Completion deadline as well. Change tracking bug should be set to the MODIFIED state to indicate it achieved completeness. Incomplete and non testable Changes will be reported to FESCo for 2017-Mar-03 meeting.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
May I ask for status update on this Change, as requested in Comment #1 ?
hey Jan, I assume you want to know if this change is "done" and/or what is left to do? Should be just waiting for https://pagure.io/releng/issue/6619 - which is releng adding the image as something that normally gets built.
Switching to ON_QA as this is now considered as testable: https://meetbot.fedoraproject.org/teams/fesco/fesco.2017-03-17-16.00.html
I believe requested information has been provided. Canceling needinfo.
<walters> does anyone know where the latest builds for https://fedoraproject.org/wiki/Changes/ContainerMinimalImage are? <walters> (and if someone does, can you edit the wiki page?) <walters> i spent a few minutes digging through https://kojipkgs.fedoraproject.org/compose/branched/Fedora-26-20170424.n.0/ and couldn't even find the non-minimal image (did that move somewhere else?) <dgilmore> walters: https://kojipkgs.fedoraproject.org/compose/branched/Fedora-26-20170424.n.0/logs/aarch64-armhfp-x86_64/imagebuild-Docker-Container_Minimal_Base-docker.aarch64-armhfp-x86_64.log <dgilmore> https://kojipkgs.fedoraproject.org/compose/branched/Fedora-26-20170424.n.0/logs/aarch64-armhfp-x86_64/imagebuild-Docker-Docker_Base-docker.aarch64-armhfp-x86_64.log <dgilmore> walters: https://github.com/redhat-imaging/imagefactory/issues/397 <walters> is the VM leaking the *cause* of the task failure or a nice-to-have? <walters> this is 32 bit arm that's failing? <dgilmore> walters: the failure is cause by imagefactory not really cleaning up after itself. or possibly koji for not making sure that the vm is really killed <walters> has an armhf build of this ever worked? <dgilmore> walters: but yes 32 bit arm is failing due to previous failure vms still running causing there to not be enough ram on the host to make a new vm <dgilmore> walters: its worked a lot <walters> does the last functioning result get pushed anywhere? <dgilmore> the cause of it is x86_64 or aarch64 failing <dgilmore> koji killing the task on other arches <dgilmore> but the killing not really sticking <dgilmore> the last functioning result is removed with the next compose <dgilmore> so no <dgilmore> with the koji update that I am testing in stage if one arch fails the others will still continue and be shipped assuming we mark the arch as non release blocking
(In reply to Colin Walters from comment #7) > <walters> does anyone know where the latest builds for > https://fedoraproject.org/wiki/Changes/ContainerMinimalImage are? There was one created on 04/20: https://kojipkgs.fedoraproject.org/compose/branched/Fedora-26-20170420.n.0/compose/Docker/x86_64/images/Fedora-Container-Minimal-Base-26-20170420.n.0.x86_64.tar.xz > <walters> (and if someone does, can you edit the wiki page?) > <walters> i spent a few minutes digging through > https://kojipkgs.fedoraproject.org/compose/branched/Fedora-26-20170424.n.0/ > and couldn't even find the non-minimal image (did that move somewhere else?) > <dgilmore> walters: > https://kojipkgs.fedoraproject.org/compose/branched/Fedora-26-20170424.n.0/ > logs/aarch64-armhfp-x86_64/imagebuild-Docker-Container_Minimal_Base-docker. > aarch64-armhfp-x86_64.log > <dgilmore> > https://kojipkgs.fedoraproject.org/compose/branched/Fedora-26-20170424.n.0/ > logs/aarch64-armhfp-x86_64/imagebuild-Docker-Docker_Base-docker.aarch64- > armhfp-x86_64.log > <dgilmore> walters: https://github.com/redhat-imaging/imagefactory/issues/397 > <walters> is the VM leaking the *cause* of the task failure or a > nice-to-have? > <walters> this is 32 bit arm that's failing? > <dgilmore> walters: the failure is cause by imagefactory not really cleaning > up after itself. or possibly koji for not making sure that the vm is really > killed Most likely this issue against oz: https://github.com/clalancette/oz/issues/230. This has been fixed upstream and there is a new version of oz that is going to be released soon. > <walters> has an armhf build of this ever worked? > <dgilmore> walters: but yes 32 bit arm is failing due to previous failure > vms still running causing there to not be enough ram on the host to make a > new vm > <dgilmore> walters: its worked a lot > <walters> does the last functioning result get pushed anywhere? > <dgilmore> the cause of it is x86_64 or aarch64 failing > <dgilmore> koji killing the task on other arches > <dgilmore> but the killing not really sticking > <dgilmore> the last functioning result is removed with the next compose > <dgilmore> so no > <dgilmore> with the koji update that I am testing in stage if one arch fails > the others will still continue and be shipped assuming we mark the arch as > non release blocking