OVN has been evolving a lot since it was announced over a year ago. The project is being developed by many developers from VMware, Red Hat, IBM, eBay and other companies and individuals. If you haven’t had a chance to give it a try, recent work in the networking-ovn project has resulted in fairly complex and realistic deployment topology using Vagrant. I encourage you to have a look at the reference architecture referenced above, it’s very realistic and has come from actual production deployments of OVN with OpenStack.
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.
Brent Salisbury, otherwise known as networkstatic, has been doing an amazing job writing articles on how to run Docker Machine on various cloud platforms. He’s written about running it on Microsoft Azure, Amazon Web Services, Rackspace Public Cloud, and Digital Ocean. He’s done an amazing job showing you how you can utilize Docker Machine with an existing cloud platform to experiment with Docker and even use it in production running in VMs on public clouds.
[Updated 6-2-2015 with the full process for filing RFEs in Neutron.] Starting with the development of the Juno release, the Neutron project moved to using a specs repository similar to how other projects were using them. In our quest to enforce a waterfall design model, we also added an appropriate spec template which was filled with things such as “Problem Description”, “REST API Impact”, “IPv6 Impact”, “Community Impact”, and everyone’s favorite sections on “Testing” and “Documentation.” We deployed this with the best of intentions and the greatest of hopes.
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.
One of the most interesting new features in Neutron for the Kilo release is the addition of subnetpools to the API. This work was initially targeted to integrate nicely with pluggable IPAM. Unfortunately, this did not make it into Kilo and is targeted at Liberty. But even without pluggable IPAM as a consumer, the subnetpools addition is quite useful. Here’s an example of how you might use it. neutron net-create webapp neutron subnetpool-create –default-prefixlen 24 –pool-prefix 10.10.0.0/16 webpool neutron subnet-create –subnetpool webpool websubnet What I’ve shown above is the creation of a network, pool, and subnet for an example web application.
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.
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.
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.
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.
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.
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.
As of today, we just published the second Juno release candidate for Neutron. The expectation is this will be the final RC candidate and will become the official 2014.2 release of OpenStack Neutron. I thought I would take a moment to highlight some of the awesome work done by our community during the past 6 months. Distributed Virtual Router By far one of the largest, if not the largest, features we added as a team was the addition of Distributed Virtual Router (DVR) functionality.
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.
I was asked to present a workshop at the Spring 2014 Open Networking Users Group (ONUG) this past Monday. The workshop was focused on OpenStack and OpenDaylight. My slides are embedded below. The room I was given held about 40 people, but it was overflowing with attendees and was standing room only. It was great to see all of the interest in these two technologies! I’m a firm believer in Open Source, so seeing this level of attendance is always a welcome sight.
With the Icehouse release of Neutron impending, we’ve unfortunately uncovered a bug which is affecting ODL integration with Neutron. This bug was introduced by this commit, and the reality is better CI for the ODL plugin would have caught this. I’m going to work to enable this better CI in the near future. The workaround for this is to add the following in your nova.conf: vif_plugging_<wbr /timeout = 10 vif_plugging_<wbr /is_fatal = False I’m working on fixing this right now.
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.
I am very lucky to be a part of six great presentation submissions for the upcoming OpenStack Summit in Atlanta. The OpenStack Foundation uses voting to help decide which of these talks, panels, and tutorials will be scheduled. I would appreciate your vote for my submissions! I’ll highlight them below. Using OpenStack Within An OpenStack Environment: This is a talk which will be similar to the tutorial Madhu, Brent, Ryan and I did at the OpenDaylight Summit, except it will be less tutorial focused and more presentation based.
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.
Voting for the OpenStack Summit is now open! To vote for OpenStack Presentations for the Summit in Hong Kong, use the link provided here. The presentations being voted on now are for the conference portion of the event. There are a lot of great presentations out there. I’d like to highlight the ones I am lucky enough to be a part of here. OpenStack Neutron Modular Layer 2 Plugin Deep Dive: This is a presentation myself and Robert Kukura from Red Hat are putting together.
So, it’s now official: I am a member of the OpenStack Neutron core team. I was voted onto the team last week and made official at the weekly Neutron meeting this past Monday. I will initially focus on the Open Source plugins (Open vSwitch, LinuxBridge) and the Modular Layer 2 (ML2) plugin. I wanted to thank Mark McClain for nominating me! The OpenStack Neutron core team is a great group of developers to work with, I’m very excited to continue contributing to OpenStack Neutron going forward!
Last week I attended the OpenStack Summit in Portland. This was my fifth OpenStack Summit, and a lot has changed since I attended my first OpenStack Summit in Santa Clara in 2011. Everything about this spring’s event was bigger: The crowds, the demos, the design summits. It was pretty awesome to see how far OpenStack has come, and even more exciting to see how much is left to be done. So many new ideas around virtual machine scheduling, orchestration, and automation were discussed this week.
As we get closer to the OpenStack Summit next week in Portland, I wanted to reflect back on the last 6 months of my community involvement with OpenStack. It was almost 6 months ago when I created the Minnesota OpenStack Meetup in an attempt to drive some discussions, education, collaboration, and community around OpenStack in the Twin Cities. Since that time, the Minnesota OpenStack Meetup group has grown to over 120 members (at 127 at the time of this writing).
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.
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.
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.
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.
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.