<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 16, 2015 at 8:20 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Adding -dev because of the reference to the Neutron "Get me a network spec". Also adding [nova] and [neutron] subject markers.<br>
<br>
Comments inline, Kris.<br>
<br>
On 05/22/2015 09:28 PM, Kris G. Lindgren wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
During the Openstack summit this week I got to talk to a number of other<br>
operators of large Openstack deployments about how they do networking.<br>
  I was happy, surprised even, to find that a number of us are using a<br>
similar type of networking strategy.  That we have similar challenges<br>
around networking and are solving it in our own but very similar way.<br>
  It is always nice to see that other people are doing the same things<br>
as you or see the same issues as you are and that "you are not crazy".<br>
So in that vein, I wanted to reach out to the rest of the Ops Community<br>
and ask one pretty simple question.<br>
<br>
Would it be accurate to say that most of your end users want almost<br>
nothing to do with the network?<br>
</blockquote>
<br>
That was my experience at AT&T, yes. The vast majority of end users could not care less about networking, as long as the connectivity was reliable, performed well, and they could connect to the Internet (and have others connect from the Internet to their VMs) when needed.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In my experience what the majority of them (both internal and external)<br>
want is to consume from Openstack a compute resource, a property of<br>
which is it that resource has an IP address.  They, at most, care about<br>
which "network" they are on.  Where a "network" is usually an arbitrary<br>
definition around a set of real networks, that are constrained to a<br>
location, in which the company has attached some sort of policy.  For<br>
example, I want to be in the production network vs's the xyz lab<br>
network, vs's the backup network, vs's the corp network.  I would say<br>
for Godaddy, 99% of our use cases would be defined as: I want a compute<br>
resource in the production network zone, or I want a compute resource in<br>
this other network zone.  The end user only cares that the IP the vm<br>
receives works in that zone, outside of that they don't care any other<br>
property of that IP.  They do not care what subnet it is in, what vlan<br>
it is on, what switch it is attached to, what router its attached to, or<br>
how data flows in/out of that network.  It just needs to work. We have<br>
also found that by giving the users a floating ip address that can be<br>
moved between vm's (but still constrained within a "network" zone) we<br>
can solve almost all of our users asks.  Typically, the internal need<br>
for a floating ip is when a compute resource needs to talk to another<br>
protected internal or external resource. Where it is painful (read:<br>
slow) to have the acl's on that protected resource updated. The external<br>
need is from our hosting customers who have a domain name (or many) tied<br>
to an IP address and changing IP's/DNS is particularly painful.<br>
</blockquote>
<br>
This is precisely my experience as well.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Since the vast majority of our end users don't care about any of the<br>
technical network stuff, we spend a large amount of time/effort in<br>
abstracting or hiding the technical stuff from the users view. Which has<br>
lead to a number of patches that we carry on both nova and neutron (and<br>
are available on our public github).<br>
</blockquote>
<br>
You may be interested to learn about the "Get Me a Network" specification that was discussed in a session at the summit. I had requested some time at the summit to discuss this exact use case -- where users of Nova actually didn't care much at all about network constructs and just wanted to see Nova exhibit similar behaviour as the nova-network behaviour of "admin sets up a bunch of unassigned networks and the first time a tenant launches a VM, she just gets an available network and everything is just done for her".<br>
<br>
The spec is here:<br>
<br>
<a href="https://review.openstack.org/#/c/184857/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/184857/</a><br>
<br>
> At the same time we also have a<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
*very* small subset of (internal) users who are at the exact opposite<br>
end of the scale.  They care very much about the network details,<br>
possibly all the way down to that they want to boot a vm to a specific<br>
HV, with a specific IP address on a specific network segment.  The<br>
difference however, is that these users are completely aware of the<br>
topology of the network and know which HV's map to which network<br>
segments and are essentially trying to make a very specific ask for<br>
scheduling.<br>
</blockquote>
<br>
Agreed, at Mirantis (and occasionally at AT&T), we do get some customers (mostly telcos, of course) that would like total control over all things networking.<br>
<br>
Nothing wrong with this, of course. But the point of the above spec is to allow "normal" users to not have to think or know about all the advanced networking stuffs if they don't need it. The Neutron API should be able to handle both sets of users equally well.<br>
<br>
Best,<br>
-jay<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div><div class="gmail_extra"><div class="gmail_default" style="font-family:monospace,monospace">​I'm kinda surprised there wasn't more feedback on this thread.  I mean of course besides the "this is how I do it" and "why are you doing it that way" type stuff.  Between Meetups, Conferences and Customer visits this is usually a pretty big topic in my experience.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I'm really trying to sort some of this out on my side, the reality for me is that the majority of customers that I deal with are still on Nova-Network.  Most of the feedback is "it just works" and "it's good enough".  Has anybody looked at just making a special option that basically does what Nova-Net has done for so many people for so long?</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I also completely understand that the other end of the spectrum exists out there as well and certainly not suggesting they shouldn't have the capabilities that they want.  It would be really cool however to see something like the "just give me a network" idea actually go some place, because I think for initial adoption and for (maybe) a majority of deployers that's what they seem to want.<br></div><br></div></div>