On Thu, Sep 29, 2016 at 6:45 PM, Josh Berkus <jberkus(a)redhat.com> wrote:
On 09/29/2016 03:03 PM, Adam Miller wrote:
> Hello all,
> I was recently discussing some items around docker layered image
> release process in the future with Randy (bowlofeggs) and Patrick
> (puiterwijk). As a side effect of our discussion there were two
> questions I wanted to ask of the Cloud WG:
> 1) Do we want to maintain docker images for every Fedora Release or do
> we want to focus only on latest? (i.e. - do we want to maintain them
> like we do rpms or take a different position)
By "images" do you mean "base image" or "layered images"?
Layered Images, the base images will only sport the tag of their major
release number as they do today: 24, 25, 26, etc etc.
Basically each layered image has a single application for which we are
about the version. The version of Fedora underneath that is fairly
inconsequential, but major version of the application can be very important.
Take everyone's favorite destruction test case, PostgreSQL. For
Postgres, replication doesn't necessarily work between major versions,
so once we put out a major version we need to keep it out.
If we have a PostgreSQL-9.5.3 image on Fedora 24 Base out there, then:
A. it's OK to replace it with a PostgreSQL-9.5.4 image on Fedora 24
B. it's OK to replace it with a PostgreSQL-9.5.4 image on Fedora 25
C. it's NOT OK to drop it any only have a PostgreSQL-9.6.1 image available
I have mixed feelings about whether or not we should do (B) as policy.
In cases like this, I usually come down to: what's easier? Freezing the
base image for the major version of the application, or advancing it?
I think both ways can pose their own challenges, if we freeze on each
version then Layered image maintainers have to pay attention to
multiple Fedora releases but if we focus only on the latest then there
will be a cut over period where some people end up broken because of
unforeseen side effects of the base image upgrade.
> 2) Do we want to keep around multiple versions of a container?
> For example:
> If we had the following images:
> One we release to stable 0.95-1.25, can we delete -1.24 and/or
> -1.23? What kind of retention do we want here? (Note that rpm content
> does not currently maintain a N and N-1 in the repositories)
Just so you know, cockpit has moved to integer version numbers. Current
release is 119.
I am aware, this is just an old example I pulled out of a stage koji
build I grabbed from a while back for the sake of explaining the
If I could have anything I wanted, my answer would be "no, let's not
keep any old versions around." I certainly don't think that we should
keep any more old versions around than we absolutely have to.
Doesn't that run into the Postregesql example you gave above? If we
truly only did one image per thing, we'd break everyone with the 9.5.4
-> 9.6.1 cut over wouldn't we?
However, there's a problem with that, which is existing Docker practice.
Devs are taught to use specific versions of containers, and not
":latest", because for many images on Docker Hub "latest" is some
experimental version. It's going to be hard for us to change that. And
if they use specific versions in some build script, then they're going
to expect that version to be around when they use the same build script
6 months later. If we break that regularly, we'll just lose.
One thing we can do to ameliorate that is make sure we name images after
the major version of the app and not after the patch release, i.e. the
PostgreSQL container will be
Not the way RPM files are named, like:
... which means that we don't need to keep older patch releases and
build versions around.
However, that doesn't help us *at all* with "continuous release"
projects like Cockpit which don't have separate major releases, just
incremental releases every week. I'm not sure how to handle those; how
do we do it for RPMs right now?
RPMs have the native concept of Version-Release which actually mean
something to the package manager, Docker does not so we're basically
just attempting to assign meaning to an arbitrary string that could
very well be "blargh". RPM also has the concept of transactions which
define stages of the install as preinstall, install, and postinstall
(there are also finer grained triggers but that's out of scope). As a
side effect of this, all of rpm/yum/dnf know what to do in the senario
of 'upgrade', but docker does not.
> Josh Berkus
> Project Atomic
> Red Hat OSAS
> cloud mailing list -- cloud(a)lists.fedoraproject.org
> To unsubscribe send an email to cloud-leave(a)lists.fedoraproject.org