<html><body><p><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></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 02:02 PM</tt><br><tt>> Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed <br>> 'default' network model</tt><br><tt>> <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. </tt><br><br><br><tt>Just curious to know how many floating IPs you have in each instance of your OpenStack cloud.</tt><br><br><tt>Best,</tt><br><br><tt>Mohammad</tt><br><br><br><br><br><tt>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 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 of OpenStack<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 floating IP to get<br>> > > an outbound address, the others directly attach you to the public network.<br>> > > Most of those 8 allow you to create a private network, to boot vms 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 "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 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 "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 bepassed to<br>> > > satisfy the "you have more than one network" - the nics 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 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>> > > 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>> __________________________________________________________________________<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></tt><BR>
</body></html>