#59 Process for determining when and why Docker trusted images need to be rebuilt
Closed None Opened 5 years ago by scollier.

We have several Docker trusted images hosted on the Docker index:

https://index.docker.io/u/fedora/

These are built from the Fedora Cloud github account here:

https://github.com/fedora-cloud/Fedora-Dockerfiles

We need a clear process for deciding when these layered images need to be rebuilt. Is it when new RPMs are released? Security errata? Changes to config files? What are other criteria that could trigger the need for a rebuild?


Good questions! What about RPMs that are in the image but not used? Can we filter those out? What about a distinction between the primary application for that image vs. other rpms used in its construction?

Also, do we want these to track the latest Fedora release, or should we have separate ones for F19, F20, F21, rawhide....?

And if so, do they have different policies? Maybe rawhide rebuilds on any change, current release rebuilds on security updates + any update to the primary application, previous release rebuilds on security updates only?

Will take first crack at this, then send to the list for revisions.

Some thoughts on this ticket:

  • An option as well is for Fedora to run a registry. There are several advantages to this, some disadvantages.

  • We need to decide if we acutally build all of these - some of them are what I'd call examples, not something you'd expect to run directly

Leaving this open, but setting the milestone to beta and removing the meeting tag. Going to consider this mostly solved since the feedback I've gotten has been pretty much positive. Have a few questions to address, but I think this is mostly done.

Closing this ticket as part of trac clean up process. If you want to reopen, please reopen it after we move to pagure.io as atomic-wg.

Login to comment on this ticket.

Metadata