#69: Fedora Cloud image boot: Y U SO SLOW?
------------------------------+-------------------------------
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: major | Milestone: Fedora 21 (Alpha)
Component: Cloud Base Image | Keywords:
------------------------------+-------------------------------
In openstack using June 26th rawhide
(http://koji.fedoraproject.org/koji/taskinfo?taskID=7078357) boot is
really slow. It's about 25 seconds (as per the boot log) to a command
prompt, but another 20 seconds until the root resize is done, and another
20 before cloud-init completes.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/69>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#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
On Thu, 2016-09-29 at 16:51 -0600, Chris Murphy wrote:
> But I don't
> think QA clearly understands what cloud image(s) are release blocking,
> as previously they were just the non-atomic images.
I don't know what's going on with all this crap, but so far as I'm
concerned I understand perfectly well what the release blocking images
are. It's the ones listed on the release blocking images page which
specifically exists for this purpose:
https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fe…
(we still need to make the canonical version of this a JSON file
somewhere and generate the human-readable version from the JSON, but
meh, I haven't got around to it yet).
if it doesn't say 'yes' there, it ain't release blocking. Maintaining
that thing is the program manager's problem (i.e. jkurik's), not mine,
but it does somewhat concern me the number of 'TBD's on there. I don't
think the question of what images are 'release blocking' for F25 should
be *remotely* live at this point: it should have been decided weeks
ago, at least by Alpha release. And so far as I remember it, that's
what the protocol was supposed to be, we weren't still supposed to be
kicking around 'is it blocking?' discussions at Beta freeze. I'd
personally be very unhappy with any attempt to significantly change
what that page says right now.
Which images are prominent on the download pages and how much of a
relationship there is between that and 'release blocking' status is
*also* not my problem, but I'd agree with you (Chris) that it'd be
rather strange for the most prominently advertised deliverable for a
given product not to be a release-blocking one.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
#160: Ship fedora-motd in F24 atomic image
--------------------+---------------------
Reporter: rtnpro | Owner: rtnpro
Type: task | Status: new
Priority: normal | Milestone: Future
Component: --- | Keywords: meeting
--------------------+---------------------
fedora-motd-0.1.3-1 has been tested and moved to stable F24 repo. We need
to come up with a plan to ship it an upcoming Fedora 24 atomic cloud
images.
https://bodhi.fedoraproject.org/updates/FEDORA-2016-c8948356b9
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/160>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#155: Decide on post-GA update cadence for various deliverables
-------------------------+---------------------
Reporter: maxamillion | Owner:
Type: task | Status: new
Priority: normal | Milestone: Future
Component: --- | Keywords: meeting
-------------------------+---------------------
Currently there are plans to update release deliverables more formally
post Fedora 24 GA. These aren't all going to happen immediately following
the release but work will be done to enable them ASAP.
Some of these we've already decided on in the past but a couple still need
decisions. The goal here is to simply determine what we would like to see
as an ideal release cadence of updated deliverables. Technical
implementation and details will be outside this scope.
https://fedoraproject.org/wiki/Fedora_Program_Management/Updating_deliverab…
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/155>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#144: f23 atomic iso configures docker loopback storage
-------------------------+--------------------
Reporter: jasonbrooks | Owner:
Type: defect | Status: new
Priority: major | Milestone: Future
Component: --- | Keywords:
-------------------------+--------------------
ISO installs of f23 atomic get configured w/ loopback storage, which is a
bad thing: http://www.projectatomic.io/blog/2015/06/notes-on-fedora-
centos-and-docker-storage-drivers/.
F22 Atomic had the correct config.
Running "docker info" on a VM installed from Fedora-Cloud_Atomic-
x86_64-22.iso yields:
{{{
...
Storage Driver: devicemapper
Pool Name: fedora-docker--pool
Pool Blocksize: 65.54 kB
Backing Filesystem: extfs
Data file:
Metadata file:
...
}}}
Running "docker info" on a VM installed from Fedora-Cloud_Atomic-
x86_64-23.iso yields:
{{{
...
Storage Driver: devicemapper
Pool Name: docker-253:0-153054-pool
Pool Blocksize: 65.54 kB
Backing Filesystem: extfs
Data file: /dev/loop0
Metadata file: /dev/loop1
...
}}}
I looked over the kickstarts, but I'm not clear on what might be causing
this.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/144>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
#167: Decide a process about failed tests for Autocloud
--------------------+---------------------
Reporter: kushal | Owner:
Type: task | Status: new
Priority: normal | Milestone: Future
Component: --- | Keywords: meeting
--------------------+---------------------
If we have a test failing the compose (right test, catching a real bug),
should we stop the release till the time the bug gets resolved?
My personal opinion is yes, first fix, and then only go ahead.
For example [https://apps.fedoraproject.org/autocloud/jobs/353/output#283
this test] fails time to time on the vagrant virtualbox image.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/167>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System