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.
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.
I chose to remove Disqus comments from my blog. After reading about all the issues around the tracking and privacy concerns, I just decided it wasn’t worth it for my users. So the best way to comment on this blog going forward is through Social Media outlets. I’ll keep looking for a better option, but for now, that’s what I can offer.
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.
A quick note that I’ve changed my blog over to using Hugo now from Wordpress. The process itself was quite easy, and this now allows me to host the blog itself anywhere I want. I’m still playing with the process itself, but I’m finding the ability to blog using “vi” and save using github is already a huge win.
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.
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 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.
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.
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.
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).
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.
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.
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.
For the last few months, TimeMachine has been failing for me between my Macs and a QNAP TS-659 NAS I have. The NAS is running firmware 4.0.3, and I would consistently get the error “Cannot connect” when trying to connect. I was able to work around this with the following command run manually: sudo tmutil setdestination -ap afp://TimeMachine@192.168.64.38/TMBackup Running that in a terminal window allowed me to then use the GUI to select that disk for backups and things started rolling again.
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.
Automate all the things! (thanks to Hyperbole & A Half & http://memegenerator.net/X-All-The-Things) The image above got me thinking a lot about DevOps and automation. Increasingly, as large scale IaaS clouds are deployed, the first hurdle people hit is around automation. When they arrive at this problem, and my guess it’s pretty early in the cycle, they inevitably turn to an automation tool such as Puppet or Chef. These tools allow for automating pretty much anything you want around deployment, configuration, and management.
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.
My previous blog post showed you how to setup Open vSwitch (including LACP port-channels) on your Fedora 17 host. Once you have this working, creating virtual machines and adding them to one of your Open vSwitch bridges is the next logical step. For this setup, we will make use of libvirt to manage our virtual machines. We’ll utilize virt-manager (a GUI) and virsh (a CLI) to manage the VMs on the host.
I’ve recently decided to move some of the virtual infrastructure in my lab onto Fedora 17. I’ll be running my VMs on KVM utilizing libvirt to manage the VMs. The great thing about this setup is that in theory, by utilizing libvirt, I can easily move my infrastructure to something like oVirt or OpenStack in the future. But for now, I plan to simply make use of a combination of virsh and virt-manager.
On top of being a software engineer, I’m also the father of 3 kids. My daughter recently turned 8, and she is my oldest. I’ve been having her try out different methods of learning to program already, but nothing had really stuck. But I think this is about to change, as I recently discovered the wonderful website KidsRuby. After spending some time with KidsRuby over the last few days, it’s become clear there is interest enough to keep my daughter entertained and learning.
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.
This post by Brad Casemore is rather interesting. Specifically, I love this comment: When it comes to technologies and markets, our inherent optimism occasionally is thwarted by our intrinsic resistance to change. This is true everywhere, but especially true in technology. I’m not saying SDN won’t penetrate the enterprise market, and neither is Brad. It will take time, for sure. What will help SDN penetrate this market is the value built on top of it.
Subject stolen from the eloquent MG Siegler, who writes here about his feelings on comments on blog posts. I have to say, I agree 100% with him. I’ve spent way too much time trolling spam comments over the last few months. I realized it’s just not worth it. Like MG says, anyone who wants to respond to a post on this site can do so by contacting me on twitter.
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.
So, Cisco (disclaimer: I work at Cisco, although not in the group working on the NSSxxx products) has recently decided to stop selling their Qnap OEM’d NAS devices. See the link here. For those of us who have one of these in our labs (I have a NSS326 myself), this means no more firmware updates from Cisco. But, the latest firmware for these devices from Cisco (version 1.5, Release Notes PDF here) does allow for users to migrate from Cisco firmware to the stock Qnap firmware.
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.
Just a note that over the weekend, after a few weeks of reviews, the Open vSwitch Kernel Code has moved upstream. Dave Miller pulled the code this weekend. Getting this upstream will be really helpful for OpenStack Quantum, as the default plugin for that code uses OVS. This is also great for distributions who want to include OVS, but have been hesitant because of it’s lack of existence in the upstream kernel.
With all the hoopla surrounding SDN, in all of it’s forms, I thought it would be interesting to look at a possible predecesor to OpenFlow, at least in spirit: The ForCES protocol. From RFC 5810, we have the following description of ForCES: Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE).
I’ve recently started attending IRC meetings. Since I run a Mac, I had to do some digging to understand the best possible IRC clients out there. Fairly quickly, I discovered LimeChat. It’s a very versatile IRC client, the UI is pretty clean, and it doesn’t appear to suck a ton of resources. Overall, I’m quite happy with it, and would recommend it for anyone looking for a slick IRC client on the Mac.
With all of the talk regarding Software Defined Networks (SDN), it’s easy to get lost trying to understand where the value will be. The general consensus here is that value will be built on top of SDN. SDN is, in essence, a building block. One interesting project providing value by using SDN as a building block is the RouteFlow project. The goal of the project, taken straight form the front page, is: RouteFlow is an open source project to provide virtualized IP routing services over OpenFlow enabled hardware.
A recent project had me looking into useable Unit Test Frameworks for the “C” programming language. After doing some initial research, wikipedia ended up showing me a large list of frameworks, of which the majority appear to be dead or not used anymore. After doing some initial scanning, I decided to look into a handful: I initially looked into check. This one is mostly current, still appears to be maintained, and looks like a large list of open source projects use this for their own unit test needs.
This week I am traveling to San Jose for the oVirt Kickoff Workshop. Future posts will likely detail the events of the event, but for this post I wanted to talk about Tech Gear for traveling. I recently upgraded my aging Nokia N900 to a new iPhone 4S . Given the plethora of apps in the app store, I was curious to try and travel with and utilize the iPhone almost exclusively for this trip.
So, you’ve somehow stumbled onto Silicon Loons, and you may be wondering what exactly this place is. Let me summarize it for you by saying we at Silicon Loons hope to share our experiences with virtualization, networking, storage, and telecommuting. We’ve done some fun things over the years, and thought it was time to start sharing with a broader audience. So stay tuned for the fun to follow. Oh, and you may be thinking why the Loons part?