I recently made the decision to invest in a home WiFi router which could provide a VPN client right from the router for my home. Having in the past been a huge fan of Asus routers, and currently owning a Netgear Nighthawk router, I made the decision to move back to Asus. I acquired an Asus RT-AC88U. I did this because it has a beefy dual-core Arm CPU, 512MB of RAM, and even better, a community has developed around adding a few additional features to it without requiring DD-WRT or OpenWRT.
I recently had the honor of being on the OVS Orbit podcast. Ben Pfaff has been doing these shows for a short time, and I was happy to join him and discuss open source development processes as they relate to Open Source networking projects. One key note which Ben calls out is something I firmly believe in, and wanted to quote and paste below: Kyle’s advice: plan ahead, research the projects, give your developers time to become comfortable with the projects, treat everyone with respect, treat everyone equally, and give back to the core of the project.
Recently, I’ve been spending an increasing amount of time building a virtual networking layer. Of course, I’m doing this using both Open vSwitch as well as OVN. I’ve been lucky enough to be a part of a few talks on OVN, so I won’t go into many details on OVN here. But I will say we’ve found it to be a great solution to solving virtual networking at scale. What I’d like to discuss here is some of the things we’re testing with regards to OVN at scale.
I’ve been the OpenStack Neutron for 3 releases in a row. I started in Juno, was re-elected for Kilo, and then again for Liberty. This time, I’m no longer running to be the Neutron PTL anymore. I am really proud of what the team has accomplished while I was the PTL. I’m proud of not only the technical achievements, but also the community building and societal changes Neutron has undergone. All of this was accomplished with the help of some amazing people who likely spent as much time ensuring Neutron was a healthy place for new developers as they did fixing bugs and adding features.
My good friend Flavio Percoco published an excellent blog post recently about what it means to be an OpenStack PTL from his perspective. Having served as OpenStack Neutron PTL for 3 cycles now, I found his post very timely and it accurately reflects what I believe anyone wanting to run for an OpenStack PTL position should consider before making the decision to run. The post is so well written it’s hard for me to quote a single part, but I’ll try here: Before even start writing your candidacy, please, ask yourself why you want to be a PTL.
It’s crazy for me to think the OpenStack Summit is over now. All the planning which goes into making the event happen and then, just like that, it’s over before you even know it. I wanted to take a moment to reflect back on my own experiences and memories before they become faded. The Good Without question, the event staff did a tremendous job. The venue was perfect. Vancouver is one of the most beautiful cities I’ve ever had the pleasure of visiting.
The spring 2015 OpenStack TC elections are underway right now. It’s great to see the number of candidates, 19 in all, who have the desire to help shape OpenStack from the TC level. This shows there is still a real interest in being on the TC. Each of the candidate’s emails shows what they view as important and how they hope to address the issues they deem relevant to the tasks at hand.
As we near the end of the OpenStack Kilo release, I wanted to take a moment to write about a few things around Neutron’s Kilo release. In a lot of ways, Kilo was all about continuing to scale the development model for Neutron going forward. We did accomplish some feature work, as well as a lot of technical debt repayment. But the main focus was on how to continue evolving Neutron the platform.
We’re nearing the end of the Kilo development cycle. This is typically where the rubber meets the road, as we’re trying our hardest to merge a lot of code near the end. It’s a fairly busy part of the cycle. I wanted to take a moment to write about two efforts which will help to scale Neutron development in Kilo and beyond. The Kilo cycle has involved a couple of efforts which are meant to expand and scale the Neutron development community.
From this post by Ivan Pepelnjak around the usage of no-name laptops vs. Apple products by industry pundits espousing the value of whitebox switching: There’s a simple litmus test: look at the laptop they’re using. Is it a no-name x86 clone or a brand name laptop? Is it running Linux or Windows… or are they using a MacBook with OSX because it works better than any alternative (even Windows runs better on a MacBook than on a low-cost craptop).
It’s time for everyone to vote for presentations for the upcoming OpenStack Liberty Summit! As is always the case, there are a lot of great presentations submitted, and the community is charged with voting for the talks they’d like to see presented in Vancouver. With so many great options, I wanted to take this chance to share the talks I am humbled to be a part of. I am particularly excited to have a chance to discuss Neutron 101 with my good friend Mark McClain.
Now that we’re past a very busy December which included the Neutron mid-cycle in Lehi, Utah, the Neutron Spec Proposal and Approval Deadline, the Kilo-1 release of Neutron, as well as some holiday’s enjoyed around the world in December, I thought it was time to take a moment and blog about where we are in Neutron, and some of the important changes coming in the Kilo release. These changes will affect everyone from developers to deployers, from operators to packagers.
Note: This post was co-authored by my good friend Thomas Graf. My last post was around how to effectively contribute to an Open Source community. This post received a fair amount of traction, and I was happy with the conversation it created around Open Source contributions. There are plenty of people who hopefully benefited from this discussion. Recently, I’ve been having some discussions with my friend Thomas Graf around upstream community engagement.
Since being elected as the OpenStack Neutron PTL, I’ve been mostly heads down working to ensure the Neutron project has a successful Juno release. Increasingly, and especially near OpenStack Juno milestone deadlines, I’m seeing frustration from new contributors around their contributions to Neutron. I sent an email to the openstack-dev mailing list this morning addressing this in a terse form, this blog is an attempt to expand upon that email. An increasing concern I see from people who are new contributors is the perceived issues in getting their code merged into Juno.
There has been a flurry of press around Cisco’s release of OpFlex. If you want the nitty gritty details, please read the IETF draft available here. What exactly is OpFlex? The IETF draft sums it up nicely: The OpFlex architecture provides a distributed control system based on a declarative policy information model. The policies are defined at a logically centralized policy repository (PR) and enforced within a set of distributed policy elements (PE).
My good friend Dave Meyer just wrote a great blog post at SDN Central available here. A key point which Dave makes is this: Now, if we step back and ask what is implied by these three observations, you begin to see an important and profound macro trend: Engineering artifacts themselves are no longer the source of sustainable advantage and/or innovation. Rather, sustainable advantage is achieved through engineering systems, organizational culture, and the people and process that comprise the community (and/or organization).
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.
Minnesota OpenStack Meetup 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.
Recently, as I was talking to a friend about OpenStack, oVirt, and other Open Source Cloud and Virtualization technologies, he stopped me and had me back up. This friend has a strong background in VMware technologies, but not so much with their Open Source counterparts. It occurred to me there are others who may be coming from the same VMware background, thus I decided to create a handy cheat sheet for folks new to Open Source Cloud and Virtualization technologies who have a VMware background.