Re: [Qemu-devel] [PATCH 0/7] docker: update Ubuntu and Fedora images, deprecate old ones

[Daniel P. Berrange]

On Wed, Jan 17, 2018 at 10:58:21AM -0300, Philippe Mathieu-Daudé wrote:
> On 01/17/2018 07:25 AM, Daniel P. Berrange wrote:
> > On Wed, Jan 17, 2018 at 10:26:36AM +0800, Fam Zheng wrote:
> >> On 01/12/2018 08:49 PM, Philippe Mathieu-Daudé wrote:
> >>> Hi,
> >>>
> >>> This series is to be clearer about which upstream version we are using.
> >>>
> >>> All "FROM distrib:latest" entries have now been removed and replaced by
> >>> explicit "FROM distrib:version" ones.
> >>>
> >>> To keep backward compatibility, a warning is displayed to the user,
> >>> suggesting which correct base image to use.
> >>>
> >>> To be consistent, we remove the deprecated images of the "make docker" 
> >>> output.
> >>
> >> Changing image names when a new release comes out is not maintainable for
> >> Fedora and Ubuntu because of the fast pace. Therefore I prefer Paolo's
> >> simple patch.
> > 
> > The flipside is that if we release QEMU 2.12 with fedora:27, then for as  
> > long
> > as the 2.12 stable branch exists, dockers tests run on that branch will 
> > have a
> > consistent target and will be unlikely to break.  If we use fedora:latest,
> > then every time a new Fedora comes out there's non-trivial chance that 
> > docker
> > builds on all the stable branches will all break due to some new glibc 
> > change.
> > Sticking with explicit named versions is a big win in this respect IMHO.
> 
> What happened to me twice is checking an older QEMU tag while bisecting
> and being unable to run 'make docker-test' because the older QEMU tag
> use 'latest' which is not the current 'latest' from the Docker library,
> and I had to manually change the tag to the version 'latest' was
> pointing to at the time of the QEMU tag release.
> 
> On each stable release we need to freeze the current tag in a new
> Dockerfile, and keep the generic Dockerfile following the 'latest' tag.
> 
> Once tagged different that 'latest' the Dockerfile isn't suppose to
> change. So we only maintain the 'latest' version.
> 
> Fam/Alex/Daniel do you agree with this approach?

I don't see a benefit to that as opposed to just updating git master
to the most recent Fedora stable release every 6 months. In fact it is
more work, because it'll require special action by whomever actually
makes the releases.

Even in git master the use of 'latest' is causing pain. A patch series
of mine passed when i run it in docker because it pulled down fresh
f26 image to my machine, but it failed in patchew because patchew had
latest resolving to a previously cached f25 image. Using explicit
versions all the time will avoid this kind of caching problem.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|