Open Mic Spotlight: Aaron Rosen

Aaron RosenThis post is part of the OpenStack Open Mic series to spotlight the people who have helped make OpenStack successful as we celebrate the third birthday of the project. Each day in July, a new contributor will step up to the mic and answer five questions about OpenStack, cloud, careers and what they do for fun.  

Aaron Rosen currently works on OpenStack for Nicira/VMware. Most of his time is spent working on the Network Side (Neutron), though he also dabbles in the compute side (Nova). He’s most interested in networks, especially virtual ones. He graduated with a Masters in Computer Engineering from Clemson University in 2012, and joined Nicira right out of school. 

1. What’s the most critical feature you think cloud software needs to be widely adopted over the next year?

I would have to say Software Defined Networking (SDN). The network has been one of the major bottlenecks in the time that it takes to provision a new application. In addition, using traditional networking techniques such as VLANs are hard to manage and have scaling limitations. With SDN, it enables networks to be self service entities where users can provision networks, routers, load balancers, firewalls, etc. on demand via a self service portal, and deploy their application immediately. Previously, one would have to submit a help ticket and wait for the IT department to process it (some days or weeks later). In my opinion, this is one of the most important features of cloud and what the OpenStack Neutron (formerly Quantum) project aims to solve.

2. What is the most important contribution you’ve made that will make OpenStack users happy?

My most important contribution that I’ve made to OpenStack was the Security Group API implementation in Neutron. In Folsom, if one wanted to use security groups, one would need to use Nova’s security group implementation, which had a few limitations that we wanted to fix. The first limitation was that Nova security groups implementation did not work in conjunction with overlapping IP addresses. Since the point of Neutron was to let people have self-service control over their networking and addressing, this meant it was hard to use security groups with Neutron at all.  In addition, Nova’s security groups did not support egress filtering unless a tenant enforced this themselves within the instance.

Egress filtering allows tenants to enforce, which end hosts and protocols their instances are able to initiate communication with, which is useful if one wants to lock down who their instances can communicate with.

The last part of the security group work was to implement the ability for Nova to proxy its security group calls to Neutron. This is important because it allows one to create an instance via Nova and specific security groups in Neutron in addition to allowing existing scripts/tools to continue to work and allows Nova’s EC2 security group implementation to work with quantum.

3. Describe an interesting OpenStack deployment that you were part of, and why others ought to know about it. What made that project work? Tick?

At VMware we have an internal OpenStack cloud (~200 servers) that we use to host test/dev workloads and labs to demo our software to customers in addition to dogfooding our software on before it gets to customers. The interesting part of this deployment is that all of our developers use this as their primary development environment.

When I first joined the company, everyone was issued a server to run their VMs on that they were responsible for maintaining and running backups. Now, over a year+ since this cloud has been deployed, nearly every developer has returned their server that previously sat under their desk as it was no longer needed. I think what makes this deployment work is the dedicated and talented team that is tasked with maintaining this cloud and the open mindedness that its users have in the power that cloud provides. I’d have to say this is probably one of the most sophisticated cloud deployments out there powered by OpenStack with Nicira NVP for SDN, running both KVM and ESX hypervisors. I’m also proud to admit that we successfully upgraded this cloud from OpenStack Folsom to Grizzly a few months back!

4. What other open source projects do you think work well with OpenStack, and why?

  • Python! — Nuff said (Everything in OpenStack is written in Python.)
  • Open vSwitch — A programmable software virtual switch that most neutron plugins leverage to implement SDN.
  • Gerrit ( — There are a few things I don’t like about it, but all in all I think it works well in order to keep track and review the massive amount of patches against OpenStack.

5. How would you suggest to someone that they should pick OpenStack for deployment? What is the most compelling argument for OpenStack in your mind?

The compelling arguments that I would raise for deploying it would be that OpenStack is backed by a large community of users and companies. There are a large number of service providers deploying OpenStack, which allows you to cloud burst on demand to leverage public OpenStack clouds using the same automation you’ve already built around the OpenStack APIs.

Most importantly though, that it allows you to have flexibility to pick the best in class components from a variety of vendors rather then being forced into a vertically integrated stack.

Leave a Reply

Your email address will not be published. Required fields are marked *