<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap:break-word">
I would agree from the standpoint that most users don't want to care about the network but the majority of the users are folks that want a higher level of service then just raw compute resources too.<br>
<br>
They want an app catalog where they can get fully featured, reliable, scalable, and secure cloud enabled apps that they can just deploy and consume, and not care about any of the details. The same way you go to McDonalds and get a hamburger and not want to
care about the huge scalable pipelines they have had to develop to get it from cow/field all the way to you.<br>
<br>
It is the cloud application developers, that need to write the cloud apps that the end users above will consume, those are the folks that will care that features like NaaS exists as a common feature on clouds since those types of apps usually require that sort
of functionality. If its not common, its hard for their apps to get consumed. So simply asking if the majority of users want/care about feature X, when they don't know or don't care to look that deeply into it doesn't mean they don't need it and ops don't
need to provide it, simply that they don't care to know how hamburger is made. As the app catalog progresses, I believe it will become increasingly important.<br>
<br>
Thanks,<br>
Kevin <strong>
<div><font face="Tahoma" color="#000000" size="2"> </font></div>
</strong>
<hr tabindex="-1">
<font face="Tahoma" size="2"><b>From:</b> Kris G. Lindgren<br>
<b>Sent:</b> Friday, May 22, 2015 6:28:44 PM<br>
<b>To:</b> openstack-operators@lists.openstack.org<br>
<b>Subject:</b> [Openstack-operators] How do your end users use networking?<br>
</font><br>
<div></div>
<div>
<div><font face="Calibri,sans-serif">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.</font></div>
<div><span style="line-height:16px; white-space:pre-wrap; widows:1"><br>
</span></div>
<div><span style="line-height:16px; white-space:pre-wrap; widows:1">Would it be accurate to say that most of your end users want almost nothing to do with the network?</span></div>
<div><br>
</div>
<div id="magicdomid2812" class="ace-line" style="margin:0px; padding:0px; white-space:pre-wrap; line-height:16px; widows:1">
<span class="author-a-lz89z2chz80zz88zz73z8d14cz88zz72zz67z" style="margin:0px; padding:1px 0px">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.
</span>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. </div>
<div id="magicdomid2814" class="ace-line" style="margin:0px; padding:0px; white-space:pre-wrap; line-height:16px; widows:1">
<br style="margin:0px; padding:0px">
</div>
<div id="magicdomid2844" class="ace-line" style="margin:0px; padding:0px; white-space:pre-wrap; line-height:16px; widows:1">
<span class="author-a-lz89z2chz80zz88zz73z8d14cz88zz72zz67z" style="margin:0px; padding:1px 0px">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).
</span>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. <font face="Calibri,sans-serif" style="font-size:14px"> </font></div>
<div style="font-size:14px; font-family:Calibri,sans-serif; color:rgb(0,0,0)">
<div>
<div>____________________________________________</div>
<div> </div>
<div>Kris Lindgren</div>
<div>Senior Linux Systems Engineer</div>
<div>GoDaddy, LLC.</div>
</div>
</div>
</div>
</body>
</html>