As OpenStack marches towards it’s Icehouse release this spring, some work I’ve been doing has finally merged upstream. This week, both the OpenDaylight ML2 MechanismDriver and devstack support for OpenDaylight merged upstream. This was a huge effort which spans the efforts of many people. This was the first step in solidifying the integration of OpenDaylight with OpenStack Neutron, and we have many additional things we can do. To get a first taste of running the two together, please see the video of the OpenDaylight Summit presentation myself, Madhu Venugopal, and Brent Salisbury did in early February.
If you’re a fan of networking, you are no doubt very excited by all of the recent excitement in the industry as of late. And there is no larger area of innovation in networking at the moment than Open Source networking. Two of the projects at the forefront of Open Source networking innovation are OpenStack Neutron and OpenDaylight. OpenStack Neutron is driving an API around networking for Infrastructure as a Service Clouds, and has been very successful at driving mindshare in this area.
Last week I was in New Orleans for LinuxCon. This was my first LinuxCon event, and it was pretty awesome. The event was co-located with a smattering of other Open Technology events as well:
CloudOpen Linux Plumbers Conference Xen Project User Summit OpenDaylight Mini Summit Gluster Workshop 2013 ENEA North America Hacker Event UEFI Plugfest Linux Wireless Summit Linux Security Summit As you can see, that’s a lot of events to pack into a single week.
Recently, I had a need to create a multi-node OpenStack Folsom deployment with Quantum. I needed to test out some deployment scenarios for a customer. To make things even more interesting, I wanted to test it out with the recent VXLAN changes in Open vSwitch which went upstream. I thought others may be interested in this as well. I’m planning to document this for Grizzly as well, but the steps should be mostly the same.
Yesterday I hosted the first Minnesota OpenStack Meetup at the local Cisco office in Bloomington. It was an event I had been planning for about 2 months. I was very excited to meet with other Stackers in the Twin Cities. But the story starts much before this, I’m getting ahead of myself a bit here. Let me backup and tell you the full story of how the Minnesota OpenStack Meetup came to be.
If you read the libvirt development mailing list, you will have noticed that libvirt released 2 versions this week, the latest of which is version 0.10.1. This version includes a bunch of bug fixes, but between this and the previous 0.10.0, there are some changes in how you work with Open vSwitch virtualport types. I thought I’d explain some of them here, as they are advantageous and will make deploying libvirt with Open vSwitch easier.
Many readers of this blog, as well as my work on the Open@Cisco Blog, will be familiar with both OpenStack and oVirt. I have written many posts on OpenStack and oVirt, but what I want to do with this post is compare the two. Examining where each project has it’s roots, as well as it’s current status and how the two Open Source projects may converge in the future, is a worthy exercise.
So, it should come as no surprise that I’m a big Fedora user. I’ve been running Fedora since Core 1 came out years ago, and I’ve always been a happy user. As my world has converged around OpenStack recently, the easiest way to work in this environment is by using devstack. For a long while, devstack only workd with Ubuntu. It now supports Fedora, as well as using Qpid instead of the regular RabbitMq.
It’s that time of year again where everyone goes off on email. Fred Wilson does it here, and MG Siegler does it here. I quote from MG’s article here:
The only real “solution” is to change the way people think about email. It needs to be considered more of a stream than an inbox. That is, it needs to be more like Twitter and less like a to-do list.
As much as everyone hated Google Wave, it was ahead of it’s time in changing how email was used.
So, previously on the other site I blog for, I mentioned VXLAN in OpenStack Quantum. The reasons for this are dictated in that post. While we can start working on the segment ID and multicast address management in Quantum, getting VXLAN support into Open vSwitch can be done in parallel. That process has seen renewed interest recently (see the thread here), and I am happy to report I have setup a git repository with the patches from last fall merged into the latest master branch versions of Open vSwitch.