Testimonial #1
by Joe Brockmeier
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/
9 years, 4 months
cloud image network config, virtio-net, libvirt autodetection, and network vs NetworkManager, F20 vs F21
by Colin Walters
TL;DR:
KB, I think the CentOS cloud images should use:
https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f21&id=98...
Dennis, we should revert:
https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f21&id=5a...
Longer story:
I tried the CentOS 7 GenericCloud image:
http://cloud.centos.org/centos/7/devel/
and it didn't have networking on boot. Let's look at the actors:
- A base cloud image: Fedora 20, Fedora 21, CentOS 7
- Network configuration: As specified in the kickstart
- A network driver: virtio-net, rtl8139
- virt-install guest autodetection: Determines whether or not you get virtio-net
- network system (or NetworkManager, or systemd-networkd)
- systemd: http://lists.freedesktop.org/archives/systemd-devel/2014-July/020906.html
- Anaconda/kickstart behavior
First, let's look at the current F20:
https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-b...
It hardcodes eth0. And the version of systemd there uses eth0 for virtio-net.
Now, let's look at some changes Dennis committed in the F21 cycle:
ens3:
https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f21&id=e1...
link:
https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f21&id=98...
eth0 (but only for atomic):
https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?h=f21&id=5a...
(Dennis and others, can you send patches to the list for review? This issue would have been more obvious if I'd noticed the changes going by)
A really critical variable here is whether or not libvirt guest autodetection works. Currently:
libvirt automatically provides virtio-net: Fedora 20, Fedora 21 Generic
libvirt gives you rtl8193: Fedora 21 Atomic, CentOS 7
It took me a while to figure out here that the reason the CentOS 7 image wasn't working was becuase of the libvirt autodetection.
I have this utterly trivial "create-cloud-vm.sh" script I've been using:
https://gist.github.com/cgwalters/a366c14b2fc58e0f7367
It does work if I specify --os-variant rhel7 for CentOS7. Which I'm now going to start doing by default in my script (I don't use it to boot anything else).
But...the change to do DHCP on all links by default is also an important change. One we should highlight in the release notes.
9 years, 4 months
Fedora Cloud meeting on 2014-11-19
by Kushal Das
===========================
#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...
.
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
9 years, 4 months
Fwd: [atomic-devel] recommending Flannel (w/ vxlan backend) for atomic -- thoughts?
by Joe Brockmeier
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/
9 years, 4 months