#150: Docker container refresh cadence ----------------------------+--------------------- Reporter: acarter | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: Docker (Other) | Keywords: meeting ----------------------------+--------------------- I need to get a decision from this group about what refresh cadence we should target for docker containers. We've gotten proposals to refresh images based on updates passing testing and moving to stable in bodhi, based on a regularly scheduled & predictable 2 week release cycle (alternating weeks with Atomic) and (of course) both. We need clear guidance on what the requirement will be at F25 so that we can design tooling to support it. If someone has an idea of what the likely requirements after F25 will be that might help us make somewhat informed design decisions also. We plan to create an automated build -> test -> release workflow for these refreshes so that we can scale to a large set of images quickly.
#150: Docker container refresh cadence ----------------------------+--------------------- Reporter: acarter | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: Docker (Other) | Resolution: Keywords: meeting | ----------------------------+---------------------
Comment (by acarter):
Some pros and cons shared by MattDM:
I can think of several reasons that having a two-week cadence might be beneficial:
* Fights the (accurate) perception that Fedora updates are an unmanageable firehose * If some layered images represent modules, and we want the modules to work together, putting them in batches makes it easier to test that a given batch _does_ work as a coherent whole * Provides a rhythm that both users and developers can expect.
On the other hand, we NEED to be able to deliver updates out-of-cycle for critical and important updates (both security and bugfix), and it's also important to make other bugfixes (and new features) available to people who want them without having to wait.
#150: Docker container refresh cadence ----------------------------+--------------------- Reporter: acarter | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: Docker (Other) | Resolution: Keywords: meeting | ----------------------------+---------------------
Comment (by walters):
Anyone who wants newer content in the Docker base image before the two weeks can easily run yum update.
In the extremely unlikely event that we introduce new functionality that *isn't* updated RPMs, anyone who wants to try it out is quite likely to be happy to be pulling from the development CD.
This discussion almost exactly mirrors https://fedorahosted.org/rel- eng/ticket/6313 - except that right now rpm-ostree doesn't have the "run yum update" equivalent, but it will withhttps://github.com/projectatomic /rpm-ostree/pull/107
#150: Docker container refresh cadence ----------------------------+--------------------- Reporter: acarter | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: Docker (Other) | Resolution: Keywords: meeting | ----------------------------+---------------------
Comment (by maxamillion):
It was agreed upon during the meeting that this would be a two week release cadence.
#150: Docker container refresh cadence ----------------------------+--------------------- Reporter: acarter | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: Docker (Other) | Resolution: Keywords: meeting | ----------------------------+---------------------
Comment (by jzb):
Any further action here or should we close this?
#150: Docker container refresh cadence ----------------------------+--------------------- Reporter: acarter | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: Docker (Other) | Resolution: Keywords: meeting | ----------------------------+---------------------
Comment (by jberkus):
I disagree with not making exceptions for security fixes.
Running YUM Update inside containers is Doing It Wrong; many container- based infrastructures have no way to do this.
I think we should have a 2-week cadence, but make an exception for important security fixes.
#150: Docker container refresh cadence ----------------------------+--------------------- Reporter: acarter | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: Docker (Other) | Resolution: Keywords: meeting | ----------------------------+---------------------
Comment (by jberkus):
Note that I am talking here strictly about security fixes for core Linux utilities and kernel issues, not for userspace applications.
#150: Docker container refresh cadence ----------------------------+--------------------- Reporter: acarter | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: Docker (Other) | Resolution: Keywords: meeting | ----------------------------+---------------------
Comment (by scollier):
Would be good to capture these recommendations in the container best practices guide here: https://github.com/projectatomic/container-best- practices
#150: Docker container refresh cadence ----------------------------+--------------------- Reporter: acarter | Owner: Type: task | Status: closed Priority: normal | Milestone: Future Component: Docker (Other) | Resolution: fixed Keywords: meeting | ----------------------------+--------------------- Changes (by dustymabe):
* status: new => closed * resolution: => fixed
Comment:
From above: "It was agreed upon during the meeting that this would be a two week release cadence."
Closing