<div dir="ltr">Hi Kris,<div><br></div><div>Busy week! It was good seeing you in Vancouver - even if it was just in passing on the escalator ;)<br><div class="gmail_extra"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">



<div style="word-wrap:break-word">
<div><font face="Calibri,sans-serif"> 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". </font></div></div></blockquote><div><br></div><div>+100</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">
<div><span style="line-height:16px;white-space:pre-wrap">Would it be accurate to say that most of your end users want almost nothing to do with the network?</span></div></div></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">
<div><span style="line-height:16px;white-space:pre-wrap">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</span><br></div><div style="margin:0px;padding:0px;white-space:pre-wrap;line-height:16px"><span style="margin:0px;padding:1px 0px"> 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></div></div></blockquote><div><br></div><div>Again, yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div style="margin:0px;padding:0px;white-space:pre-wrap;line-height:16px">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></blockquote><div><br></div><div><div>Our use of floating IPs has been described as "overloaded" in other discussions, and I think that's accurate. Our users use floating IPs both as a way to move a common IP from one compute resource to another and as a way to attach to a publicly accessible network for direct access.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">
<div style="margin:0px;padding:0px;white-space:pre-wrap;line-height:16px">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<br style="margin:0px;padding:0px"></div><div style="margin:0px;padding:0px;white-space:pre-wrap;line-height:16px"><span style="margin:0px;padding:1px 0px"> 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></div></div></blockquote><div><br></div><div>This is the primary reason we continue to use nova-network. I'm only mentioning that to describe our implemented solution and not an attempt start a Neutron v nova-network debate. We're not opposed to Neutron.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div style="margin:0px;padding:0px;white-space:pre-wrap;line-height:16px">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></blockquote><div><br></div><div>We see the same thing. We will set up separate, smaller cloud environments where the focus is on the network and not compute. To date, these clouds have been lab environments. I'm not sure what we would do if we had users who wanted "advanced" network features in our compute-focused clouds.</div><div><br></div><div>Joe </div></div><br></div></div></div>