#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
#84: publicize fedora-dockerfiles
-------------------------------------------+-------------------------------
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: normal | Milestone: Fedora 21 (Final)
Component: Collaboration & Communication | Keywords: meeting
-------------------------------------------+-------------------------------
https://github.com/fedora-cloud/Fedora-Dockerfiles is
a) cool
b) useful
c) active
d) a great place for new contributors
We should popularize this. Articles, blog posts, wiki documentation, non-
wiki documentation, etc.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/84>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#97: Maintaining Fedora docker images for f22
-----------------------------------+-----------------------
Reporter: jzb | Owner:
Type: task | Status: new
Priority: blocker | Milestone: Fedora 22
Component: Docker Base Container | Keywords: meeting
-----------------------------------+-----------------------
f22 docker alpha images were not tested or really looked after afaict.
According to dgilmore we have pulled in server pkgs instead of cloud, and
have cockpit packages coming into the container. That's bad. We need to
see who "owns" testing of the base images.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/97>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#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
Hey cloud team,
I think we need some cloud docs. Fedora has a lot to offer in the cloud
area, and I'm sure that those engaged in the space are excited that
Fedora has what they are looking for. The uninitiated, on the other
hand, are looking for what Fedora has, and we can do better to
demonstrate that.
We have a cloud guide,
https://git.fedorahosted.org/cgit/docs/cloud-guide.git/ . It covers
some basics, ie euca2ools, but never really made it out of draft state,
and your work has left it far behind. We don't have anyone on the Docs
team fully engaged to track the cloud space, or anyone on the cloud team
engaged to maintain that guide. Also, it's written in docbook, and a
lot of folks aren't into that.
So, as I'm working on some tooling for a new Fedora Docs site, I'd like
to know what would get *you* into writing about Fedora Cloud. In the
most direct sense, it's a question about markup and delivery, ie a
collection of markdown or reStructuredText files in a git repo. In a
broad sense, anything along the lines of "I would write docs for using
Fedora Cloud, if..." would be great.
Hopefully, we can find some balance between cloud and writing expertise
and deliver something exciting. At this point, I'm focusing on enabling
you; let's work that out.
--
-- Pete Travis
- Fedora Docs Project Leader
- 'randomuser' on freenode
- immanetize(a)fedoraproject.org
#92: Need rootfiles package in fedora:latest Docker base image
-----------------------------------+--------------------
Reporter: scollier | Owner:
Type: task | Status: new
Priority: normal | Milestone: Future
Component: Docker Base Container | Keywords:
-----------------------------------+--------------------
We need the .bashrc in order to properly change the bash prompt once
changed into the image.
For example, here's the fedora:20 image:
-bash-4.2# docker run -it fedora:20 bash
[root@845950cd95f1 /]# cat /etc/fedora-release
Fedora release 20 (Heisenbug)
[root@845950cd95f1 /]# rpm -qf /root/.bashrc
rootfiles-8.1-16.fc20.noarch
For example, here's the fedora:latest image:
-bash-4.2# docker run -it fedora:latest bash
bash-4.3# rpm -qf /root/.bashrc
error: file /root/.bashrc: No such file or directory
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/92>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#86: qcow2 images text is a bit obscure / OpenStack-only
----------------------------+--------------------
Reporter: jzb | Owner: jzb
Type: task | Status: new
Priority: normal | Milestone: Future
Component: Website & Wiki | Keywords:
----------------------------+--------------------
Lars Kellogg-Stedman sent a note to the Fedora Cloud list today noting,
rightly, that the libvirt audience might miss the qcow2 images because
it's labeled "OpenStack" (only) rather than being more expansive.
We need to correct this and add instructions for using cloud-init with the
image in Virt-Manager, etc.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/86>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
Hey all, I wanted to start a thread about doing more frequent Atomic releases in Fedora.
In particular I'd like to start building a new atomic release every two weeks that
includes the latest version of Docker, Kubernetes, and OSTree for the Fedora Atomic
images.
The problem I'm trying to solve here is that there is a lot of work going on upstream in
the Docker and Kubernetes communities and there isn't a very good way to consume that
upstream work on a Red Hat/Fedora/CentOS system today. By focusing on more regular
releases, we can fix some of the issues we've seen (like demoing new features at a
conference that people can't actually use).
There are still some details to work out like whether to base this image on Fedora
$CURRENT or rawhide and what to do when the builds fail. Fortunately, this can possibly
be done without much additional change to the release process. We're already rebuilding
the docker/kubernetes/ostree rpms almost daily, and there are nightly builds as well
(at least in rawhide).
If we can pull a 2 week process off, I'd like to see that followed by a 4 week process
in CentOS which will behave similarly but with the slightly slower-moving, more stable bits.
Thoughts?
[1] http://www.projectatomic.io/download/
--
Mike McGrath | mmcgrath(a)redhat.com | (312) 660-3547
Atomic | Red Hat Chicago | http://projectatomic.io/