#150 Docker container refresh cadence
Closed None Opened 3 years ago by acarter.

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.


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.

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

It was agreed upon during the meeting that this would be a two week release cadence.

Any further action here or should we close this?

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.

Note that I am talking here strictly about security fixes for core Linux utilities and kernel issues, not for userspace applications.

Would be good to capture these recommendations in the container best practices guide here: https://github.com/projectatomic/container-best-practices

From above: "It was agreed upon during the meeting that this would be a two week release cadence."

Closing

Login to comment on this ticket.

Metadata