Bug 1421688 - Container Minimal Image
Container Minimal Image
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: Changes Tracking (Show other bugs)
26
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Dusty Mabe
ChangeAcceptedF26, SelfContainedChange
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-02-13 07:58 EST by Jan Kurik
Modified: 2017-07-25 13:05 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-25 13:05:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Kurik 2017-02-13 07:58:55 EST
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.
Comment 1 Jan Kurik 2017-02-28 05:08:47 EST
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.
Comment 2 Fedora End Of Life 2017-02-28 06:16:21 EST
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.
Comment 3 Jan Kurik 2017-03-01 04:52:08 EST
May I ask for status update on this Change, as requested in Comment #1 ?
Comment 4 Dusty Mabe 2017-03-01 21:45:04 EST
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.
Comment 5 Jan Kurik 2017-03-21 05:17:10 EDT
Switching to ON_QA as this is now considered as testable: https://meetbot.fedoraproject.org/teams/fesco/fesco.2017-03-17-16.00.html
Comment 6 Dusty Mabe 2017-03-27 08:13:42 EDT
I believe requested information has been provided. Canceling needinfo.
Comment 7 Colin Walters 2017-04-24 17:34:55 EDT
<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
Comment 8 Dusty Mabe 2017-04-24 17:41:05 EDT
(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

Note You need to log in before you can comment on or make changes to this bug.