Hey all,
So dgilmore pointed out that f22 docker images will not have yum
installed - which means we need to update the Dockerfiles for f22 to use
dnf and not yum.
We probably ought to go through and sanity-check them all to ensure they
work with the f22 image as well before, say, beta.
I'm CC'ing Scott b/c, if I'm not mistaken, he's done quite a lot of the
work so far on the Dockerfiles - but also, I think he's looking for
assistance there in keeping the effort going.
Best,
jzb
--
Joe Brockmeier | Principal Cloud & Storage Analyst
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/

#99: AMI lifetimes (Cloud WG members vote needed)
-------------------------------------+-------------------------------------
Reporter: oddshocks | Owner: oddshocks
Type: task | Status: new
Priority: normal | Milestone: Fedora 22
Component: Infrastructure & | Keywords: aws, images, vote,
Release Engineering | policy
-------------------------------------+-------------------------------------
This ticket is to discuss and vote on appropriate lifetimes for Fedora
Cloud AMIs on our official and community cloud accounts, as discussed on
the Cloud SIG list this month[1] and in this week's meeting.
Everyone seems to agree that after a final release, all TC, RC, Alpha,
Beta, and scratch builds should be deleted. This makes sense because
there'd be no reason to use any of these AMIs after the final release.
Still, we need to definitively decide on:
1. When should TC, RC, Alpha, Beta, and scratch builds be deleted? (1)
After a final release? (2) Progressively, when a newer build of the same
type comes out? (3) After a set amount of time, depending on the build
type? Note that with (2) or (3), we'd need some way to mark each build
with it's type. I don't think that necessarily happens now.
2. When should final release AMIs be deleted? (1) After a certain number
of newer final releases? (2) After a certain amount of time? (3) Never?
Also note that if we choose any age-based deletion policies, we'd need to
set up some sort of regular polling of *all* our AMIs on both accounts.
We want to hold as few AMIs at one time as is reasonable. There are many
AMIs created for each image build that happens, so our AWS storage charges
will become quite high if we don't keep our accounts clean. Discuss, and
then perhaps a vote?
[1]:
https://lists.fedoraproject.org/pipermail/cloud/2015-March/005087.html
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/99>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System

#94: Producing Updated Cloud/Atomic Images
------------------------------+---------------------
Reporter: dustymabe | Owner:
Type: task | Status: new
Priority: normal | Milestone: Future
Component: Cloud Base Image | Keywords: meeting
------------------------------+---------------------
We need to finalize our policy around producing updated images and then
start doing it.
Right now we have loosely decided to release new images once a month or
whenever security updates require it.
Additionally, as part of this we should also decide on a policy that
determines when we stop updating images for a particular release. I
imagine that we don't want to be producing updated images for Fedora X, Y,
and Z all at the same time. Ideally we would only be producing updated
images for the current/latest major version.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/94>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System

This is a strawman based on my understanding of current abilities,
available software/systems, and of what the developers want. Please
poke holes, reorder, add and subtract, etc.
Phase I
1. F22 trees built nightly (already happening)
2. Images built from those nightly (I think right now only rawhide?)
3. Images go through automated tests, automatically (tunir; not fully
automatic yet, right?)
4. Every two weeks, latest image to pass those tests gets linked
on atomic.fpo, again all automatically (NEEDS DESIGN AND CODE)
- probably need a manual override
- page will present these images with appropriate setting of
expectations ("fedora qa not to blame for anything here").
- need something to happen if there aren't any that pass for
two weeks, which should not happen I hope, but, y'know)
* automatic message about image being out of date
* next successful image automatically posted? Or do we
skip two weeks?
- also needs: commitment to follow and fix if things break
Phase II
5. Ability to include packages from a side tag, repo, something.
All full, legit Fedora packages destined for main repo but maybe at
a different speed. (Implementation needs work)
- possibly initially just selected packages from updates-testing?
Phase III
6. Something to only expose Atomic users to _update sets_ that pass the
tests (because, hey, we have tests!)
7. Presumably, there will be a switch to F23 as base at F23 release;
will there be overlap (beta images) to make that smooth?
8. What else?
Phase IV
9. Expand tests beyond tunir — test installs on hardware, etc.
10. Maybe create a new, special Fedora repository for packages
with version skew mainline Fedora — e.g. newer systemd
or hold older Docker version for some reasons. (Up for
discussion — that's why this is in phase 3!)
11. More what else?
Does this seem basically sane and in line with what people are
expecting? What's missing? What's extra? What's just wrong? :)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader

#96: Atomic as separate spin (or, going the other way, main cloud edition)?
-------------------------+---------------------
Reporter: mattdm | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Future
Component: --- | Keywords: meeting
-------------------------+---------------------
See https://lists.fedoraproject.org/pipermail/cloud/2015-March/004996.html
I'm wondering if we should consider:
A. Move Atomic out of the Cloud Edition, and treat it as a spin, with a
home at "http://atomic.fedoraproject.org/" (not currently valid),
similar to http://kde.fedoraproject.org — with its own design, theming,
etc.
B. The other way around: double down on Atomic as the primary thing the
Cloud WG releases as the Fedora cloud product. Here, the focus would be
more on containers as the basis for the future of "cattle-style"
scale-out computing, and Atomic as Fedora's cool solution for that.
of course, it's always an option to do
C. Keep as it is, with both options presented as equals for different
cases.
Personally, I like "B" from a high-level Fedora perspective, as it's an
opinionated solution for a target use case. That's what we _want_ for the
Fedora Editions — Wrkstation is a software dev desktop, Server focuses on
role deployment via rolekit and cockpit.
On the other hand, it's a pretty big bet on Atomic, and maybe we're not
ready for that (or collectively don't think that it's the right bet).
"C" would be a more cautious wait-and-see approach.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/96>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System