Open Stack

During the Openstack summit this week I got to talk to a number of other operators of large Openstack deployments about how they do networking.  I was happy, surprised even, to find that a number of us are using a similar type of networking strategy.  That we have similar challenges around networking and are solving it in our own but very similar way.  It is always nice to see that other people are doing the same things as you or see the same issues as you are and that "you are not crazy". So in that vein, I wanted to reach out to the rest of the Ops Community and ask one pretty simple question.

Would it be accurate to say that most of your end users want almost nothing to do with the network?

In my experience what the majority of them (both internal and external) want is to consume from Openstack a compute resource, a property of which is it that resource has an IP address.  They, at most, care about which "network" they are on.  Where a "network" is usually an arbitrary definition around a set of real networks, that are constrained to a location, in which the company has attached some sort of policy.  For example, I want to be in the production network vs's the xyz lab network, vs's the backup network, vs's the corp network.  I would say for Godaddy, 99% of our use cases would be defined as: I want a compute resource in the production network zone, or I want a compute resource in this other network zone.  The end user only cares that the IP the vm receives works in that zone, outside of that they don't care any other property of that IP.  They do not care what subnet it is in, what vlan it is on, what switch it is attached to, what router its attached to, or how data flows in/out of that network.  It just needs to work. We have also found that by giving the users a floating ip address that can be moved between vm's (but still constrained within a "network" zone) we can solve almost all of our users asks.  Typically, the internal need for a floating ip is when a compute resource needs to talk to another protected internal or external resource. Where it is painful (read: slow) to have the acl's on that protected resource updated. The external need is from our hosting customers who have a domain name (or many) tied to an IP address and changing IP's/DNS is particularly painful.

Since the vast majority of our end users don't care about any of the technical network stuff, we spend a large amount of time/effort in abstracting or hiding the technical stuff from the users view. Which has lead to a number of patches that we carry on both nova and neutron (and are available on our public github). At the same time we also have a *very* small subset of (internal) users who are at the exact opposite end of the scale.  They care very much about the network details, possibly all the way down to that they want to boot a vm to a specific HV, with a specific IP address on a specific network segment.  The difference however, is that these users are completely aware of the topology of the network and know which HV's map to which network segments and are essentially trying to make a very specific ask for scheduling.
____________________________________________

Kris Lindgren
Senior Linux Systems Engineer
GoDaddy, LLC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150523/8c6e9aac/attachment.html>