OpenStack Project Technical Lead Interview Series #1: Mark McClain, OpenStack Networking Project
We are introducing the the first of a continuing series of interviews with OpenStack Project Technical Leads on our Mirantis blog. Our goal is to educate the broader tech community and help people understand how they can contribute to and benefit from OpenStack. Naturally, these are the opinions of the interviewee, not of Mirantis. We’ve edited the interview for clarity and post length.
Our first interview is with Mark McClain, newly elected OpenStack Networking Project (formerly known as “Quantum”) Technical Lead.
Mirantis: Tell us about yourself and how you got started with OpenStack.
Mark McClain: I’m a Senior Cloud Developer at DreamHost and I work on the Cloud Team. DreamHost hired me specifically to work on OpenStack. I was hired during the middle of the Essex cycle, and the cool thing about working on OpenStack, and specifically OpenStack Networking, is it combines two of my favorite things: networking and Python.
Q: What are your responsibilities? What do you find yourself doing on a day to day basis?
A: During the Grizzly release, I was a core contributor focusing on improving the metadata service functionality when using overlapping IP networks. I also worked on database migration so that folks who were deploying OpenStack can seamlessly upgrade from Folsom to Grizzly. During Grizzly, I also led several sub-teams including the L3, database, and bug triage teams.
Now as PTL, I take a much larger view of the project. I'm responsible for running our weekly team meeting and organizing the Network track at the design summit. On a daily basis, I'll correspond with the community, coordinate with sub-team leads, review code submissions, triage bugs, and review blueprints. I'll also coordinate with other members of the Foundation and Technical Committee on cross-project issues.
Q: What is it that makes OpenStack Networking so special? Why does it matter?
A: With Nova you can spin up virtual machines and it provides basic network capabilities. But when you want to use newer technologies, say, tunneling to provide network isolation between tenants or VXLAN – you can’t really leverage those with Nova networking. It limits you to VLAN’s or flat networking. The new technologies enable the biggest benefits of OpenStack Networking: scalable tenant isolation.
Q: What has the OpenStack Networking community accomplished so far, and what are your plans for the Havana release?
A: OpenStack Networking was originally created at the Diablo Summit. It was an incubator project during Essex and it was integrated in Folsom. During the Essex and Folsom time frame the community really spent a lot of time trying to reach feature parity and build many L2 and L3 features into OpenStack Networking.
In Grizzly we were able to shift focus to adding new services, and also closing the parity gap with Nova Networking. In the Grizzly cycle we added overlapping metadata services, migrations, and security groups. Another big feature of Grizzly was load balancing.
As a matter of fact, several folks from Mirantis actually helped contribute to load balancing. That was a big community project that involved multiple people from various vendors who all worked together to produce an API and the foundation for load balancing.
In Havana we’re going to extend the load balancing service and add more features. Looking forward there are vendors in the community working to improve OpenStack Networking's by adding VPN support, enterprise level ACL support, and IPv6 support. Right now the IPv6 functionality is pretty basic and folks want to add some high level services on top of that. Also there are companies and community members working on bare metal support, full multi-host support, providing HA in a little smaller context similar to what Nova multi-host is ... also there are several community members who come together to work on other user facing features.
Q: What is genuinely unique about OpenStack Networking or is it just an open source version of Networking as a Service as it already exists?
A: I think the most unique thing about OpenStack Networking compared to almost any of the other Networking as a Service solutions is a very vibrant vendor community. During the Grizzly cycle we added five new plug-ins from different vendors. That’s one of the unique things about OpenStack Networking. It also shows a lot of vendor momentum because most of the vendors have chosen to put their energy and their efforts behind OpenStack.
If you were to compare that to other networking solutions in some other cloud stacks, they have maybe one or two options if you’re lucky. You’re pretty much stuck with the networking option of the stack.
Q: What are some use cases where OpenStack Networking really shines?
A: In multi-tenant environments where isolation and security are a must you can get those systems up and running rapidly and provide those services to tenants, whether it’s a public or private cloud and you can get them running at scale fairly quickly.
In the case of smaller deployments OpenStack Networking can be configured to support even smaller private clouds fairly easily using open source tools. Smaller shops that have limited resources still can take advantage of many of the same features that the folks who are deploying at scale can as well.
Q: When you say “fairly quickly,” can you quantify that?
A: For a smaller shop, just following the OpenStack guides - if you’re familiar with OpenStack - that would be half a day. If you’re unfamiliar with OpenStack, maybe a day or two. The guides will walk you through and get you set up with a pretty realistic set-up that works well for the majority of cases.
The nice thing is you can do that with the minimal level staff and it all runs on commodity hardware. You don’t need special switches or servers. For those who are trying to experiment and figure out if OpenStack or OpenStack Networking is the solution for them, they can use gear that most businesses have in their labs anyway for testing.
Q: How about the know-how base that you need to have to get OpenStack Networking up and running?
A: It’s the same set of skills that you would find if you had a network engineer or even a DevOps type of position. You really only need a basic familiarity for deploying IP networks.
So there’s really no special skills that are needed because a lot of what the plug-in authors have done - both open source and proprietary - is abstracted out a lot of the details of knowing the extreme specifics of certain protocols so that the deployer can focus on the API’s.
Q: Are there any misconceptions about OpenStack Networking?
A: We don’t battle too many misconceptions with OpenStack Networking. I think most people understand what it does. Some folks will choose to still deploy Nova networking for new installations because they’re concerned about OpenStack Networking's complexity, maturity or stability.
Now the support materials for installation have caught up and the distributions have done a really good job of packaging OpenStack, so that is no longer the case. For new deployments, you should use OpenStack Networking from the beginning and leverage those features now, versus starting with Nova-network and eventually having to migrate to OpenStack Networking, which is a non-trivial migration.
During Havana, the OpenStack Networking and Nova teams are going to be discussing: How do we bridge that gap and how does OpenStack Networking become the default network provider for Nova?
Q: How about OpenStack Networking scalability?
A: There are several large deployments running OpenStack Networking. Some are running versions of Folsom, and some people are actually running trunk which is really interesting because it speaks to the maturity of codebase.
Q: Does OpenStack Network Project still have any “childhood ailments”?
A: We spent a lot of time in Grizzly working on isolated metadata services. A lot of the support questions we got and bug reports after the Folsom release were: How does metadata service work? - and so we spent a lot of time making sure that metadata service was a lot easier to configure and just worked out of the box for a wide variety of deployments. In Grizzly that’s probably one of the biggest diseases that we’ve gotten rid of.
Q: Who would you like to see contributing to OpenStack Network Project ?
A: We’re very fortunate. We have contributions from some very well respected companies including: Arista, BigSwitch, Brocade, Cisco, HP, IBM, NEC, Nicira, Juniper, Midokura, Plumgrid, and VMware. During the Grizzly cycle we added even more companies and some new start-ups who are offering their solutions so that drives innovation in the community.
As far as the ideal contributor ... it’s somebody who is excited about networking and wants to participate in the OpenStack community, and is willing to trade ideas back and forth amongst the different contributors so that at the end of the day the community benefits as a whole.
Q: What are the biggest opportunities for folks who want to create something awesome and outstanding in OpenStack Network Project?
A: There will be a big push in Havana for VPN-as-a-Service in several different deployment modes. Also, we’ll extend load balancing. In Grizzly we took the baby steps of getting it out and there’s several vendors who are now trying to leverage that API. IPv6 support is also going to be big as well. More internet service providers are offering v6 services for business deployments. Ensuring that OpenStack Network Project works for the various deployment modes of IPv6 is going to be important as well.
We also have excitement around folks who are working on bare metal with OpenStack Networking and on device management in larger scale: If I’m a hardware vendor - how do I integrate my piece of hardware into OpenStack Networking? Also, we are focused on deployer topics such as: How can I provide different level service level offerings?
Q: How would you advise people who want to get started contributing to OpenStack Networking? What steps should they specifically take?
A: The first step is to obviously join the OpenStack development mailing list. It gives you a sense of what the topics are that the OpenStack Networking developers are discussing.
The OpenStack Networking team also maintains a Wiki page for starter bugs. On that page we keep track of simple links for: Here’s how to find the code reviews for the OpenStack Networking server side or the OpenStack Networking client etc. As bugs are reported we will tag the easier ones as low hanging fruit which are an excellent opportunity for new developers and contributors to jump in on the project.
That means whoever is triaging the bugs can say: “Hey, this is something that is not overly complicated and is a good way to become familiar with the OpenStack Networking code base.” We also maintain a list of community projects that would be good to start working on. By being a member of the OpenStack Networking mailing list you can recruit other members of the community and work together. It also builds up trust within the community so that those folks who were reviewing your code are working with you. You have a sense of rapport with them.
Q: Thank you very much, Mark!
A: You’re welcome!
