# F21 Blocker Review meeting
# Date: 2014-11-26
# Time: 16:00 UTC (run "date -d '2014-11-26 16:00 UTC'" to see local time)
# Location: #fedora-blocker-review on irc.freenode.net
While we just had a out of band blocker review today after the QA meeting, we'll
still be having our regularly scheduled blocker review this Wednesday. We
managed to knock out all of the blockers and FEs this morning, but still we
had 2 proposed blockers and 1 proposed FE since.
I would get ready for more proposals before the meeting on Wednesday, but if we
don't get any it should be a short meeting. Maybe this time around we can all
watch the FEsCo meeting :)
If you want to take a look at the accepted blockers, the full list can be found
here: https://qa.fedoraproject.org/blockerbugs/milestone/21/final/buglist
We'll be evaluating these bugs to see if they violate the Final
Release Criteria and warrant the blocking of a release if they're not
fixed. Information on the release criteria for F21 can be found on the
wiki [0].
For more information about the Blocker and Freeze exception process,
check out these links:
- https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
- https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
And for those of you who are curious how a Blocker Review Meeting
works - or how it's supposed to go and you want to run one - check out the SOP
on the wiki:
- https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
See you Wednesday!
[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
--
// Mike
--
Fedora QA
freenode: roshi
http://roshi.fedorapeople.org
Here's the first testimonial - big thanks to Dusty for running this down
and Major for being massively responsive!
This should be about the right length. Please lemme know if not.
"Fedora 21 gives me the balance I'm looking for - a leading edge
operating system with enterprise-level tools for fast provisioning and
configuration."
Major Hayden, Principal Architect at Rackspace
Best,
jzb
--
Joe Brockmeier | Principal Cloud & Storage Analyst
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
Dear all,
You are kindly invited to the meeting:
Fedora Cloud Workgroup on 2014-11-26 from 19:00:00 to 20:00:00 UTC
At fedora-meeting(a)irc.freenode.net
The meeting will be about:
Standing meeting for the Fedora Cloud Workgroup
Source: https://apps.fedoraproject.org/calendar//meeting/482/
IIRC somebody sent the list of AMIs but I have not been able to dig it
up -- do we have a list of AMIs for current Atomic builds to use for
tomorrow's Test Day?
Thanks,
jzb
--
Joe Brockmeier | Principal Cloud & Storage Analyst
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
===========================
#fedora-cloud: Fedora Cloud
===========================
Meeting started by kushal at 19:07:51 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-cloud/2014-11-19/fedora_cloud_sig.2…
.
Meeting summary
---------------
* Roll Call (kushal, 19:08:17)
* Previous Meeting follow-up (kushal, 19:11:22)
* ACTION: roshi to bring new criteria to QA meeting Monday
(2014-11-24) (roshi, 19:15:40)
* Plan test days for Atomic image (#74) (kushal, 19:17:57)
* Article for Fedora Magazine on "state of cloud SIG/product" for beta
release (#75) (kushal, 19:21:28)
* Fedora Magazine story will be pushed by jzb (kushal, 19:24:44)
* publicize fedora-dockerfiles (#84) (kushal, 19:25:05)
* LINK: https://twitter.com/dustymabe/status/535153359603265536
(dustymabe, 19:32:17)
* Public Uploaded Images Criteria (#80) (kushal, 19:33:59)
* participation in OpenShift Commons (83) (kushal, 19:37:40)
* Open Floor (kushal, 19:41:10)
Meeting ended at 19:59:24 UTC.
Action Items
------------
* roshi to bring new criteria to QA meeting Monday (2014-11-24)
Action Items, by person
-----------------------
* roshi
* roshi to bring new criteria to QA meeting Monday (2014-11-24)
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* kushal (99)
* roshi (90)
* dustymabe (28)
* zodbot (12)
* scollier (9)
* mattdm (9)
* jsmith (6)
* kilted1 (3)
* agrimm (3)
* oddshocks (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
Kushal
--
Fedora Cloud Engineer
CPython Core Developer
Director Python Software Foundation
http://kushaldas.in
Hey all,
Sorry - today's meeting would be 8 p.m. my time. Will try to get the
"State of Cloud" piece pushed to Fedora Magazine sometime tonight or
early tomorrow morning.
Best,
jzb
--
Joe Brockmeier | Principal Cloud & Storage Analyst
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
Upstream discussion to try to figure out which tool to use to set up
networks for Atomic/Docker.
Thoughts, comments, suggestions?
-------- Forwarded Message --------
Subject: [atomic-devel] recommending Flannel (w/ vxlan backend) for
atomic -- thoughts?
Date: Tue, 18 Nov 2014 14:36:03 -0500
From: John W. Linville <linville(a)redhat.com>
To: atomic-devel(a)projectatomic.io
Greetings,
Internally we've been doing a little looking at projects for setting-up
overlay networks between minions in a Kubernetes cluster. One of the
most interesting options has been Flannel (formerly Rudder). Flannel
requires minimal configuration to slice a large subnet into a series of
smaller subnets, one per minion running flanneld.
Flannel uses a configuration stored as a JSON file in etcd. The JSON
configuration looks a bit like this:
{
"Network": "192.168.88.0/24",
"SubnetLen": 28,
"Backend": {
"Type": "vxlan"
}
}
The above configuration would allow up to 16 minions to each allocate
a /28 subnet for use by their local docker daemon. (Larger or smaller
subnets are, of course, a simple matter of configuration.) The local
configuration information is written by flanneld to a file
under /var/run, and the info is used to pass the --bip option to docker
so that it configures its docker0 bridge appropriately.
Beyond that, the vxlan backend for flanneld on each minion creates a
vxlan tunnel endpoint and configures it to use the DOVE extensions for
routing. The route to the larger (e.g. /24) subnet points at the vxlan
interface, so traffic to other minions is directed through it. Such
traffic triggers L2MISS and L3MISS messages that are handled by
flanneld, directing traffic to the appropriate minions.
The result is a vxlan-based overlay network that enables connectivity
between all the minions (and their pods) with a minimal amount of
configuration required. This seems like a powerful and usable means to
enable this communication.
Given the description above (and whatever other sources you might have
at your disposal), does anyone have any objections to using this as a
default Kubernetes networking solution in Atomic? Or any questions
about the use of Flannel in general?
Thanks,
John
--
John W. Linville Hope is a good breakfast, but it is a
linville(a)redhat.com bad supper. -- Sir Francis Bacon
--
Joe Brockmeier | Principal Cloud & Storage Analyst
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/