Open Stack

"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/760cfadb/attachment.html>