"Fox, Kevin M" <kevin....@pnnl.gov> wrote on 09/15/2015 02:00:03 PM:
> From: "Fox, Kevin M" <kevin....@pnnl.gov> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Date: 09/15/2015 02:02 PM > Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed > 'default' network model > > We run several clouds where there are multiple external networks. > the "just run it in on THE public network" doesn't work. :/ > > I also strongly recommend to users to put vms on a private network > and use floating ip's/load balancers. Just curious to know how many floating IPs you have in each instance of your OpenStack cloud. Best, Mohammad For many reasons. Such as, if > you don't, the ip that gets assigned to the vm helps it become a > pet. you can't replace the vm and get the same IP. Floating IP's and > load balancers can help prevent pets. It also prevents security > issues with DNS and IP's. Also, for every floating ip/lb I have, I > usually have 3x or more the number of instances that are on the > private network. Sure its easy to put everything on the public > network, but it provides much better security if you only put what > you must on the public network. Consider the internet. would you > want to expose every device in your house directly on the internet? > No. you put them in a private network and poke holes just for the > stuff that does. we should be encouraging good security practices. > If we encourage bad ones, then it will bite us later when OpenStack > gets a reputation for being associated with compromises. > > I do consider making things as simple as possible very important. > but that is, make them as simple as possible, but no simpler. > There's danger here of making things too simple. > > Thanks, > Kevin > ________________________________________ > From: Doug Hellmann [d...@doughellmann.com] > Sent: Tuesday, September 15, 2015 10:02 AM > To: openstack-dev > Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed > 'default' network model > > Excerpts from Armando M.'s message of 2015-09-15 09:30:35 -0700: > > On 15 September 2015 at 08:04, Monty Taylor <mord...@inaugust.com> wrote: > > > > > Hey all! > > > > > > If any of you have ever gotten drunk with me, you'll know I hate floating > > > IPs more than I hate being stabbed in the face with a very angry fish. > > > > > > However, that doesn't really matter. What should matter is "what is the > > > most sane thing we can do for our users" > > > > > > As you might have seen in the glance thread, I have a bunch of OpenStack > > > public cloud accounts. Since I wrote that email this morning, I've added > > > more - so we're up to 13. > > > > > > auro > > > citycloud > > > datacentred > > > dreamhost > > > elastx > > > entercloudsuite > > > hp > > > ovh > > > rackspace > > > runabove > > > ultimum > > > unitedstack > > > vexxhost > > > > > > Of those public clouds, 5 of them require you to use a floating IP to get > > > an outbound address, the others directly attach you to the public network. > > > Most of those 8 allow you to create a private network, to boot vms on the > > > private network, and ALSO to create a router with a gateway and put > > > floating IPs on your private ip'd machines if you choose. > > > > > > Which brings me to the suggestion I'd like to make. > > > > > > Instead of having our default in devstack and our default when we talk > > > about things be "you boot a VM and you put a floating IP on it" - which > > > solves one of the two usage models - how about: > > > > > > - Cloud has a shared: True, external:routable: True neutron network. I > > > don't care what it's called ext-net, public, whatever. the "shared" part > > > is the key, that's the part that lets someone boot a vm on it directly. > > > > > > - Each person can then make a private network, router, gateway, etc. and > > > get floating-ips from the same public network if they prefer that model. > > > > > > Are there any good reasons to not push to get all of the public networks > > > marked as "shared"? > > > > > > > The reason is simple: not every cloud deployment is the same: private is > > different from public and even within the same cloud model, the network > > topology may vary greatly. > > > > Perhaps Neutron fails in the sense that it provides you with too much > > choice, and perhaps we have to standardize on the type of networking > > profile expected by a user of OpenStack public clouds before making changes > > that would fragment this landscape even further. > > > > If you are advocating for more flexibility without limiting the existing > > one, we're only making the problem worse. > > As with the Glance image upload API discussion, this is an example > of an extremely common use case that is either complex for the end > user or for which they have to know something about the deployment > in order to do it at all. The usability of an OpenStack cloud running > neutron would be enhanced greatly if there was a simple, clear, way > for the user to get a new VM with a public IP on any cloud without > multiple steps on their part. There are a lot of ways to implement > that "under the hood" (what you call "networking profile" above) > but the users don't care about "under the hood" so we should provide > a way for them to ignore it. That's *not* the same as saying we > should only support one profile. Think about the API from the use > case perspective, and build it so if there are different deployment > configurations available, the right action can be taken based on > the deployment choices made without the user providing any hints. > > Doug > > > > > > > > > OH - well, one thing - that's that once there are two networks in an > > > account you have to specify which one. This is really painful in nova > > > clent. Say, for instance, you have a public network called "public" and a > > > private network called "private" ... > > > > > > You can't just say "nova boot --network=public" - nope, you need to say > > > "nova boot --nics net-id=$uuid_of_my_public_network" > > > > > > So I'd suggest 2 more things; > > > > > > a) an update to python-novaclient to allow a named network to bepassed to > > > satisfy the "you have more than one network" - the nics argument is still > > > useful for more complex things > > > > > > b) ability to say "vms in my cloud should default to being booted on the > > > public network" or "vms in my cloud should default to being booted on a > > > network owned by the user" > > > > > > Thoughts? > > > > > > > As I implied earlier, I am not sure how healthy this choice is. As a user > > of multiple clouds I may end up having a different user experience based on > > which cloud I am using...I thought you were partially complaining about > > lack of consistency? > > > > > > > > Monty > > > > > > __________________________________________________________________________ > > > OpenStack Development Mailing List (not for usage questions) > > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev