[openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

Fox, Kevin M Kevin.Fox at pnnl.gov
Tue Sep 15 19:43:45 UTC 2015


I'm not quite sure how to read your question. I think it can be taken multiple ways. I'll guess at what you meant though. If I interpreted wrong, please ask again.

For the instances that have floating ip's, usually either 1 or 2. One of our clouds has basically a public
network directly on the internet, and a shared private network that crosses tenants but is not internet facing. We can place vm's on either network easily by just attaching floating ip's. The private shared network has more floating ip's assigned then the internet one usually.

As LBaaS is maturing, we're using it more and more, putting the floating ips on the LB instead of the instances, and putting a pool of instances behind it. So our instance counts are growing faster then our usage of floating IP's.

Thanks,
Kevin
________________________________
From: Mohammad Banikazemi [mb at us.ibm.com]
Sent: Tuesday, September 15, 2015 12:23 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model


"Fox, Kevin M" <Kevin.Fox at pnnl.gov> wrote on 09/15/2015 02:00:03 PM:

> From: "Fox, Kevin M" <Kevin.Fox at pnnl.gov>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at 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 [doug at 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 <mordred at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150915/3a2d3b5d/attachment.html>


More information about the OpenStack-dev mailing list