#147: Don't overwrite download location for 2 week atomic images -----------------------+--------------------- Reporter: dustymabe | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Keywords: meeting -----------------------+--------------------- Would be nice if the images don't get overwritten on each release. See discussion in this email thread:
https://lists.fedoraproject.org/archives/list/cloud%40lists.fedoraproject.or...
#147: Don't overwrite download location for 2 week atomic images -----------------------+--------------------- Reporter: dustymabe | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: meeting | -----------------------+---------------------
Comment (by jzb):
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.
#147: Don't overwrite download location for 2 week atomic images -----------------------+--------------------- Reporter: dustymabe | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: meeting | -----------------------+---------------------
Comment (by miabbott):
With the introduction of the `rpm-ostree deploy` verb, switching to older releases is very easy.
http://blog.verbum.org/2015/12/15/new-atomic-host-verb-rpm-ostree-deploy/
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
#147: Don't overwrite download location for 2 week atomic images -----------------------+--------------------- Reporter: dustymabe | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: meeting | -----------------------+---------------------
Comment (by kushal):
+1 to N and N-1 releases.
#147: Don't overwrite download location for 2 week atomic images -----------------------+--------------------- Reporter: dustymabe | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: meeting | -----------------------+---------------------
Comment (by dustymabe):
I'm obviously +1 :)
#147: Don't overwrite download location for 2 week atomic images -----------------------+--------------------- Reporter: dustymabe | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: meeting | -----------------------+---------------------
Comment (by jsmith):
+1 to this proposal.
#147: Don't overwrite download location for 2 week atomic images -----------------------+--------------------- Reporter: dustymabe | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: meeting | -----------------------+---------------------
Comment (by maxamillion):
-1
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.
#147: Don't overwrite download location for 2 week atomic images -----------------------+--------------------- Reporter: dustymabe | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: meeting | -----------------------+---------------------
Comment (by rtnpro):
+1 to the proposal.
@maxmillion,
what if the newer image introduces a bug? Users should have the option to discover older stable images.
#147: Don't overwrite download location for 2 week atomic images -----------------------+--------------------- Reporter: dustymabe | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: meeting | -----------------------+---------------------
Comment (by dustymabe):
Should I open a releng ticket for this so we can track it better?
#147: Don't overwrite download location for 2 week atomic images -----------------------+--------------------- Reporter: dustymabe | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: meeting | -----------------------+---------------------
Comment (by coreypobrien):
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.
#147: Don't overwrite download location for 2 week atomic images -----------------------+--------------------- Reporter: dustymabe | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: meeting | -----------------------+---------------------
Comment (by maxamillion):
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.
#147: Don't overwrite download location for 2 week atomic images -----------------------+--------------------- Reporter: dustymabe | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: meeting | -----------------------+---------------------
Comment (by jzb):
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?
#147: Don't overwrite download location for 2 week atomic images -----------------------+--------------------- Reporter: dustymabe | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: meeting | -----------------------+---------------------
Comment (by walters):
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.
#147: Don't overwrite download location for 2 week atomic images -----------------------+--------------------- Reporter: dustymabe | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: meeting | -----------------------+---------------------
Comment (by jasonbrooks):
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:
https://download.fedoraproject.org/pub/alt/atomic/testing/20160712.0/CloudIm... /Fedora-Atomic-Vagrant-24-20160712.0.x86_64.vagrant-libvirt.box
is the same as
https://download.fedoraproject.org/pub/alt/atomic/stable/CloudImages/x86_64/... /Fedora-Atomic-Vagrant-24-20160712.0.x86_64.vagrant-libvirt.box
For Dusty's issue w/ vagrant atlas, maybe he could link instead to the testing location?
#147: Don't overwrite download location for 2 week atomic images -----------------------+--------------------- Reporter: dustymabe | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: meeting | -----------------------+---------------------
Comment (by maxamillion):
PR in pagure to no longer overwriting stable content in-place, keeping N and N-1, added "latest" target.
https://pagure.io/releng/pull-request/101
#147: Don't overwrite download location for 2 week atomic images -----------------------+--------------------- Reporter: dustymabe | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: meeting | -----------------------+---------------------
Comment (by maxamillion):
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/... here].
Websites mailing list thread [https://lists.fedoraproject.org/archives/list/websites@lists.fedoraproject.o... here].
#147: Don't overwrite download location for 2 week atomic images -----------------------+--------------------- Reporter: dustymabe | Owner: Type: task | Status: closed Priority: normal | Milestone: Future Component: --- | Resolution: fixed Keywords: meeting | -----------------------+--------------------- Changes (by sayanchowdhury):
* status: new => closed * resolution: => fixed
-
Fedora Cloud Trac Tickets