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