<html><body><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">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">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">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">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></tt><BR>
</body></html>