#147 Don't overwrite download location for 2 week atomic images
Closed None Opened 7 years ago by dustymabe.

Would be nice if the images don't get overwritten on each release. See discussion in this email thread:


I'd be +1 to having a short retention period (like current release + current release -1 or maybe two old releases, max) but we'd quickly consume a lot of space if we retain all two-week releases.

With the introduction of the rpm-ostree deploy verb, switching to older releases is very easy.


You could argue we don't need older releases with that functionality. But for the purposes of this ticket, I'd vote for keeping current and current-1

+1 to N and N-1 releases.


The whole point of Two Week Releases, as I understood the request to Release Engineering, was to push the newest bits more rapidly than before. I don't have the motivation to continue to advertise old releases.

+1 to the proposal.


what if the newer image introduces a bug? Users should have the option to discover older stable images.

Should I open a releng ticket for this so we can track it better?

Two other considerations:
1. Right now there is no image available because the release today didn't upload an image, just a checksum (check out the ?? size http://imgur.com/1pzfCk9). Having an old image would avoid this problem.
2. Immediately removing the old image leaves no time for downstream users to update links. It would be nice to have a "latest" image available with a predictable name too.

This has been discussed offline, we have an agreed upon approach such that the stable/ directory structure will feature date stamped directories and we will keep N and N-1 stable releases there. Unfortunately this isn't a trivial change because of the way that AutoCloud and the Two Week Release system are based on different things. AutoCloud is koji task based and Two Week Release is Compose based. Currently we use a hacky heuristic check to munge together the data that's needed with proper pathing and such but as a side effect this is fragile and we'll also need to patch the Atomic website to take into account the new pathing. It's on the list of things to do and will be done as soon as there is time to get the tooling aligned.

Hi all,

How will we apply this to AMIs?

Paul Frields raised a good point in a thread about retaining images in AWS, how many AMIs for 2-week images should we retain?

What's the migration plan for users who, for whatever reason, pick an image and want to stick with it? Do we consider that a valid use case? Any idea what other folks do?

Why wouldn't AWS also be N and N-1?

As far as "picking an image", I think the burden would lie on the the consumer to copy the AMI into their infra, in the same way that people downloading the QCOW2 files are copying.

I took a bunch of notes on the issue at https://jebpages.com/notes-on-fedora-cloud-wg-147/.

One thing I notice is that the images live in the testing directory, as well, and this appears to get mirrored:


is the same as


For Dusty's issue w/ vagrant atlas, maybe he could link instead to the testing location?

PR in pagure to no longer overwriting stable content in-place, keeping N and N-1, added "latest" target.


Taking a two-pronged approach, one is a change to the releng script for keeping N and N-1, then going to submit a change to the websites code to handle the "latest" target. Mailing list threads below.

Cloud mailing list thread [https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/thread/RIVZOYPJSMTMQXHKXIWNTSWQ2CQAPNXC/ here].

Websites mailing list thread [https://lists.fedoraproject.org/archives/list/websites@lists.fedoraproject.org/thread/7L4QHLHWN4ECRMXCEMKI4JIZBSLSN7QN/ here].

Login to comment on this ticket.