On Thu, Sep 29, 2016 at 6:45 PM, Josh Berkus <jberkus@xxxxxxxxxx> 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: >> >> registry.fedoraproject.org/cockpit:0.95-1.23 >> registry.fedoraproject.org/cockpit:0.95-1.24 >> registry.fedoraproject.org/cockpit:0.95-1.25 >> >> 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 situation. > > 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 > > registry.fedoraproject.org/postgresql:9.5 > > Not the way RPM files are named, like: > > registry.fedoraproject.org/postgresql:9.5.3-021 > > ... 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. -AdamM > > -- > -- > Josh Berkus > Project Atomic > Red Hat OSAS > _______________________________________________ > cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx
