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"? 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? > > 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. 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. 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? -- -- Josh Berkus Project Atomic Red Hat OSAS _______________________________________________ cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx
