<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Ah. Instance of Cloud, not Nova Instance. Gotcha.<br>
<br>
The biggest currently has about 100 addresses on the public net and maybe about a quoter of those are allocated to instances. the shared private's about 200 and around a 30 or 40 are used. We have a lot of big vm's on that cloud for HPC like workload, so there
are only around a hundred fifty instances at present. The majority are huge, taking up a whole node. The rest are small, infrastructure related and a lot are HA behind load balancers. We're using host aggrigates to keep the workloads separate. Of the non Compute
VM's, I'd say there's somewhere between a 2x relationship between vm's without floating ip's and those with. That number's growing as we make things more HA.<br>
<br>
Thanks,<br>
Kevin<br>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF750606"><font face="Tahoma" size="2" color="#000000"><b>From:</b> Mohammad Banikazemi [mb@us.ibm.com]<br>
<b>Sent:</b> Tuesday, September 15, 2015 1:03 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model<br>
</font><br>
</div>
<div></div>
<div>
<p>Thanks Kevin for your answer. My question was different. You mentioned in your email that you run several clouds. That's why I used the word "instance" in my question to refer to each of those clouds. So let me put the question in a different way: in the
biggest cloud you run, how many total floating IPs do you have. Just a ballpark number will be great. 10s, 100s, 1000s, more?<br>
<br>
Thanks,<br>
<br>
Mohammad<br>
<br>
<tt>"Fox, Kevin M" <Kevin.Fox@pnnl.gov> wrote on 09/15/2015 03:43:45 PM:<br>
<br>
> From: "Fox, Kevin M" <Kevin.Fox@pnnl.gov></tt><br>
<tt>> To: "OpenStack Development Mailing List (not for usage questions)" <br>
> <openstack-dev@lists.openstack.org></tt><br>
<tt>> Date: 09/15/2015 03:49 PM</tt><br>
<tt>> Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed <br>
> 'default' network model</tt><br>
<tt>> <br>
> I'm not quite sure how to read your question. I think it can be <br>
> taken multiple ways. I'll guess at what you meant though. If I <br>
> interpreted wrong, please ask again.<br>
> <br>
> For the instances that have floating ip's, usually either 1 or 2. <br>
> One of our clouds has basically a public <br>
> network directly on the internet, and a shared private network that <br>
> crosses tenants but is not internet facing. We can place vm's on <br>
> either network easily by just attaching floating ip's. The private <br>
> shared network has more floating ip's assigned then the internet one usually.<br>
> <br>
> As LBaaS is maturing, we're using it more and more, putting the <br>
> floating ips on the LB instead of the instances, and putting a pool <br>
> of instances behind it. So our instance counts are growing faster <br>
> then our usage of floating IP's.<br>
> <br>
> Thanks,<br>
> Kevin</tt><br>
<tt>> <br>
> From: Mohammad Banikazemi [mb@us.ibm.com]<br>
> Sent: Tuesday, September 15, 2015 12:23 PM<br>
> To: OpenStack Development Mailing List (not for usage questions)<br>
> Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed <br>
> 'default' network model<br>
</tt><br>
<tt>> "Fox, Kevin M" <Kevin.Fox@pnnl.gov> wrote on 09/15/2015 02:00:03 PM:<br>
> <br>
> > From: "Fox, Kevin M" <Kevin.Fox@pnnl.gov><br>
> > To: "OpenStack Development Mailing List (not for usage questions)" <br>
> > <openstack-dev@lists.openstack.org><br>
> > Date: 09/15/2015 02:02 PM<br>
> > Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed <br>
> > 'default' network model<br>
> > <br>
> > We run several clouds where there are multiple external networks. <br>
> > the "just run it in on THE public network" doesn't work. :/<br>
> > <br>
> > I also strongly recommend to users to put vms on a private network <br>
> > and use floating ip's/load balancers. <br>
> <br>
> <br>
> Just curious to know how many floating IPs you have in each instance<br>
> of your OpenStack cloud.<br>
> <br>
> Best,<br>
> <br>
> Mohammad<br>
> <br>
> <br>
> <br>
> <br>
> For many reasons. Such as, if <br>
> > you don't, the ip that gets assigned to the vm helps it become a <br>
> > pet. you can't replace the vm and get the same IP. Floating IP's and<br>
> > load balancers can help prevent pets. It also prevents security <br>
> > issues with DNS and IP's. Also, for every floating ip/lb I have, I <br>
> > usually have 3x or more the number of instances that are on the <br>
> > private network. Sure its easy to put everything on the public <br>
> > network, but it provides much better security if you only put what <br>
> > you must on the public network. Consider the internet. would you <br>
> > want to expose every device in your house directly on the internet? <br>
> > No. you put them in a private network and poke holes just for the <br>
> > stuff that does. we should be encouraging good security practices. <br>
> > If we encourage bad ones, then it will bite us later when OpenStack <br>
> > gets a reputation for being associated with compromises.<br>
> > <br>
> > I do consider making things as simple as possible very important. <br>
> > but that is, make them as simple as possible, but no simpler. <br>
> > There's danger here of making things too simple.<br>
> > <br>
> > Thanks,<br>
> > Kevin<br>
> > ________________________________________<br>
> > From: Doug Hellmann [doug@doughellmann.com]<br>
> > Sent: Tuesday, September 15, 2015 10:02 AM<br>
> > To: openstack-dev<br>
> > Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed <br>
> > 'default' network model<br>
> > <br>
> > Excerpts from Armando M.'s message of 2015-09-15 09:30:35 -0700:<br>
> > > On 15 September 2015 at 08:04, Monty Taylor <mordred@inaugust.com> wrote:<br>
> > ><br>
> > > > Hey all!<br>
> > > ><br>
> > > > If any of you have ever gotten drunk with me, you'll know I <br>
> hate floating<br>
> > > > IPs more than I hate being stabbed in the face with a very angry fish.<br>
> > > ><br>
> > > > However, that doesn't really matter. What should matter is "what is the<br>
> > > > most sane thing we can do for our users"<br>
> > > ><br>
> > > > As you might have seen in the glance thread, I have a bunch ofOpenStack<br>
> > > > public cloud accounts. Since I wrote that email this morning, I've added<br>
> > > > more - so we're up to 13.<br>
> > > ><br>
> > > > auro<br>
> > > > citycloud<br>
> > > > datacentred<br>
> > > > dreamhost<br>
> > > > elastx<br>
> > > > entercloudsuite<br>
> > > > hp<br>
> > > > ovh<br>
> > > > rackspace<br>
> > > > runabove<br>
> > > > ultimum<br>
> > > > unitedstack<br>
> > > > vexxhost<br>
> > > ><br>
> > > > Of those public clouds, 5 of them require you to use a <br>
> floating IP to get<br>
> > > > an outbound address, the others directly attach you to the <br>
> public network.<br>
> > > > Most of those 8 allow you to create a private network, to bootvms on the<br>
> > > > private network, and ALSO to create a router with a gateway and put<br>
> > > > floating IPs on your private ip'd machines if you choose.<br>
> > > ><br>
> > > > Which brings me to the suggestion I'd like to make.<br>
> > > ><br>
> > > > Instead of having our default in devstack and our default when we talk<br>
> > > > about things be "you boot a VM and you put a floating IP on it" - which<br>
> > > > solves one of the two usage models - how about:<br>
> > > ><br>
> > > > - Cloud has a shared: True, external:routable: True neutron network. I<br>
> > > > don't care what it's called ext-net, public, whatever. the <br>
> "shared" part<br>
> > > > is the key, that's the part that lets someone boot a vm on it directly.<br>
> > > ><br>
> > > > - Each person can then make a private network, router, gateway, etc. and<br>
> > > > get floating-ips from the same public network if they prefer that model.<br>
> > > ><br>
> > > > Are there any good reasons to not push to get all of the public networks<br>
> > > > marked as "shared"?<br>
> > > ><br>
> > ><br>
> > > The reason is simple: not every cloud deployment is the same: private is<br>
> > > different from public and even within the same cloud model, the network<br>
> > > topology may vary greatly.<br>
> > ><br>
> > > Perhaps Neutron fails in the sense that it provides you with too much<br>
> > > choice, and perhaps we have to standardize on the type of networking<br>
> > > profile expected by a user of OpenStack public clouds before <br>
> making changes<br>
> > > that would fragment this landscape even further.<br>
> > ><br>
> > > If you are advocating for more flexibility without limiting the existing<br>
> > > one, we're only making the problem worse.<br>
> > <br>
> > As with the Glance image upload API discussion, this is an example<br>
> > of an extremely common use case that is either complex for the end<br>
> > user or for which they have to know something about the deployment<br>
> > in order to do it at all. The usability of an OpenStack cloud running<br>
> > neutron would be enhanced greatly if there was a simple, clear, way<br>
> > for the user to get a new VM with a public IP on any cloud without<br>
> > multiple steps on their part. There are a lot of ways to implement<br>
> > that "under the hood" (what you call "networking profile" above)<br>
> > but the users don't care about "under the hood" so we should provide<br>
> > a way for them to ignore it. That's *not* the same as saying we<br>
> > should only support one profile. Think about the API from the use<br>
> > case perspective, and build it so if there are different deployment<br>
> > configurations available, the right action can be taken based on<br>
> > the deployment choices made without the user providing any hints.<br>
> > <br>
> > Doug<br>
> > <br>
> > ><br>
> > > ><br>
> > > > OH - well, one thing - that's that once there are two networks in an<br>
> > > > account you have to specify which one. This is really painful in nova<br>
> > > > clent. Say, for instance, you have a public network called <br>
> "public" and a<br>
> > > > private network called "private" ...<br>
> > > ><br>
> > > > You can't just say "nova boot --network=public" - nope, you need to say<br>
> > > > "nova boot --nics net-id=$uuid_of_my_public_network"<br>
> > > ><br>
> > > > So I'd suggest 2 more things;<br>
> > > ><br>
> > > > a) an update to python-novaclient to allow a named network to <br>
> bepassed to<br>
> > > > satisfy the "you have more than one network" - the nics <br>
> argument is still<br>
> > > > useful for more complex things<br>
> > > ><br>
> > > > b) ability to say "vms in my cloud should default to being booted on the<br>
> > > > public network" or "vms in my cloud should default to being booted on a<br>
> > > > network owned by the user"<br>
> > > ><br>
> > > > Thoughts?<br>
> > > ><br>
> > ><br>
> > > As I implied earlier, I am not sure how healthy this choice is. As a user<br>
> > > of multiple clouds I may end up having a different user <br>
> experience based on<br>
> > > which cloud I am using...I thought you were partially complaining about<br>
> > > lack of consistency?<br>
> > ><br>
> > > ><br>
> > > > Monty<br>
> > > ><br>
> > > > <br>
> __________________________________________________________________________<br>
> > > > OpenStack Development Mailing List (not for usage questions)<br>
> > > > Unsubscribe: OpenStack-dev-request@lists.openstack.org?<br>
> subject:unsubscribe<br>
> > > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> > > ><br>
> > <br>
> > __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> > <br>
> > __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> > <br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</tt><br>
</p>
</div>
</div>
</div>
</body>
</html>