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. I thought I’d share some thoughts around the Summit now that things have really sunk in from last 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). We have members from all over the United States, as well as the world. I’ve really been happy to see people joining our discussions and participating in sharing their interest and knowledge around OpenStack.

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. Also, I’ve opened a blueprint for the Grizzly release to enable the selection of either GRE or VXLAN tunnels when using the Open vSwitch plugin with Quantum.

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.

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. The plugin architecture is a nice design point, because it allows open source projects as well as vendors the chance to add value and differentiate themselves at this layer. Rather than boiling things down to a commodity, Quantum provides for extensions so each plugin can expose additional information above and beyond the core API.

(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. When dealing with hundreds, thousands, and certainly hundreds of thousands of hosts, automation becomes critical. In a lot of ways, scale and automation go hand in hand. The relationship, while symbiotic in nature, works well. Scale begets automation, and more automation increases your scaling.

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. But the VMs themselves, once running on Fedora with libvirt and KVM, can easily be migrated into an oVirt setup, for instance. Perhaps a later post will detail how to go about the process of importing them into oVirt.

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. Getting Fedora 17 onto my host was quite easy, I won’t cover that here. The next thing I wanted to setup was the networking layer.

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. My main gauge has been the fact my middle son (6) has also shown interest in what his sister is doing! Both of them have spent time playing with KidsRuby over the last few days, read on for our experience.