ASUSWRT-MERLIN

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.

My Appearance on the OVS Orbit Podcast

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.

Scale Testing OVN

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.

PTL No More

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.

Being An OpenStack PTL

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.

OpenStack Vancouver Summit Wrapup

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.

Some Thoughts on the OpenStack TC Election

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.

Neutron Kilo Retrospective and a Look Toward Liberty

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.

Scaling OpenStack Neutron Development

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.

Whitebox Switching Compared to the Smartphone Market

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).

Openstack Liberty Summit Talks

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.

Test Driving an ARM-based Cloud

By now, most people have probably heard about French telecom Iliad’s plans to build a cloud running servers using ARM chips. It’s an interesting twist on the typical cloud setup for a few different reasons. Most clouds run on Intel X86 processors. Iliad’s cloud will utilize ARM-based chips in lieu of the X86 processors most public and private clouds use. Will this attract mobile developers, as Iliad hopes? Time will tell.

Neutron Splits And Spinouts

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.

OpenDaylight and OpenStack: Now With Helium!

This is just a quick post to note that the devstack support for OpenDaylight was recently updated to use the Helium release of OpenDaylight. For anyone who wants to pull down devstack and have it spin-up Neutron with OpenDaylight, you will now get the latest and greatest OpenDaylight release as a part of this. My blog post on how to use this is still relevant, so if you’re looking for instructions please look there.

Peer Reviews for Neutron Core Reviewers

As I was recently given the chance to serve as Neutron PTL for a second cycle, I thought it would be a good idea for me to share some insight into what I’m hoping to achieve upstream in Kilo. I’ll have some upcoming posts on what we’re planning on accomplishing, but I wanted to first start with a post about the actual people who are allowed to merge code into Neutron, the core reviewers.

Trust the Upstream Community

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.

How to Effectively Contribute to An Open Source Project Such As OpenStack Neutron

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.

OpFlex Is Not An OpenFlow Killer

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).

Engineering Artifacts Themselves Are No Longer the Source of Sustainable Advantage and/or Innovation

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).

OpenDaylight Integration with OpenStack has merged into Icehouse!

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.

Multi-node OpenStack Folsom devstack

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.

OpenStack, Community, and You

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.

Ryu and OpenStack: Like Peanut Butter and Jelly

OpenStack   Increasingly, I’ve been spending more and more time playing around with and utilizing OpenStack. If you’re looking for a highly configurable and quickly maturing cloud operating system, you can’t go wrong with OpenStack. One of the more interesting parts of OpenStack to a networking guy like me is Quantum. Quantum allows you to create rich topologies of virtual networks, encompassing as much or as little as you want by utilizing different plugins.

OpenStack and oVirt: Fitting the Pieces Together

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.

CloudStack Goes Apache

The announcement from Citrix that they are migrating CloudStack to the Apache Foundation under the ASL 2.0 license is a move indicative of what it takes to succeed in large scale cloud computing. Cloud computing isn’t like normal off the shelf software. Cloud computing requires building an ecosystem of developers around it. In essence, it requires a community of people deeply committed to the project. If anything, OpenStack has helped to prove this, as it’s one of the fastest growing Open Source projects ever.