#70: cloud-init output not going to the openstack log
---------------------+------------------------------
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: blocker | Milestone: Fedora 21 (Beta)
Component: --- | Keywords:
---------------------+------------------------------
Some combination of "got something wrong in the kernel parameters or where
cloud-init is sending its output".
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/70>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#43: procedures and process for getting updated images onto mirrors
------------------------------+------------------------------
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: blocker | Milestone: Fedora 21 (Beta)
Component: Software Updates | Keywords:
------------------------------+------------------------------
Right now, cloud images only get mirrored at GA release time. We need to
figure out how to ship updates.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/43>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#93: Getting sha256sum published for the cloud images
--------------------------------------------------+-----------------------
Reporter: kushal | Owner:
Type: task | Status: new
Priority: normal | Milestone: Fedora 22
Component: Infrastructure & Release Engineering | Keywords: meeting
--------------------------------------------------+-----------------------
This will help things systemd to search the images provided by Fedora in a
standard way using nspawn tool.
Example of such file from ubuntu:
https://cloud-images.ubuntu.com/trusty/current/SHA1SUMShttps://cloud-images.ubuntu.com/trusty/current/SHA256SUMS.gpg
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/93>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
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/
#88: Social Media for Dockerfiles
-----------------------------------+---------------------
Reporter: jzb | Owner: jzb
Type: task | Status: new
Priority: normal | Milestone: Future
Component: Docker Base Container | Keywords: meeting
-----------------------------------+---------------------
We need to work with marketing to tweet about things regularly. I'd like
to put out regular tweets to promote individual Dockerfiles. Thoughts?
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/88>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#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
#107: PRD Discussion
--------------------+---------------------
Reporter: roshi | Owner:
Type: task | Status: new
Priority: normal | Milestone: Future
Component: --- | Keywords: meeting
--------------------+---------------------
We need to nail down the final specifics of the PRD and turn it into the
Council for review.
Discussion here: https://fedoraproject.org/wiki/Talk:Cloud/Cloud_PRD
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/107>
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
#105: Missing Cockpit RPMs in Fedora Atomic 22
-------------------------------+-----------------------
Reporter: jzb | Owner:
Type: defect | Status: new
Priority: blocker | Milestone: Fedora 22
Component: Docker Host Image | Keywords: meeting
-------------------------------+-----------------------
We seem to be missing the cockpit rpm that includes the systemd files
(e.g. /usr/lib/systemd/system/cockpit.socket).
Can we add cockpit-ws for the next update? We'll probably not be able to
respin the images, but an atomic update can pull in the package.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/105>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System