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

Armando M. armamig at gmail.com
Tue Sep 15 23:44:04 UTC 2015


On 15 September 2015 at 15:11, Mathieu Gagné <mgagne at internap.com> wrote:

> On 2015-09-15 2:00 PM, Fox, Kevin M wrote:
> > 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. 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.
> >
>
> Sorry but I feel this kind of reply explains why people are still using
> nova-network over Neutron. People want simplicity and they are denied it
> at every corner because (I feel) Neutron thinks it knows better.
>

I am sorry, but how can you associate a person's opinion to a project,
which is a collectivity? Surely everyone is entitled to his/her opinion,
but I don't honestly believe these are fair statements to make.


> The original statement by Monty Taylor is clear to me:
>
> I wish to boot an instance that is on a public network and reachable
> without madness.
>
> As of today, you can't unless you implement a deployer/provider specific
> solution (to scale said network). Just take a look at what actual public
> cloud providers are doing:
>
> - Rackspace has a "magic" public network
> - GoDaddy has custom code in their nova-scheduler (AFAIK)
> - iWeb (which I work for) has custom code in front of nova-api.
>
> We are all writing our own custom code to implement what (we feel)
> Neutron should be providing right off the bat.
>

What is that you think Neutron should be providing right off the bat? I
personally have never seen you publicly report usability issues that
developers could go and look into. Let's escalate these so that the Neutron
team can be aware.


>
> By reading the openstack-dev [1], openstack-operators [2] lists, Neutron
> specs [3] and the Large Deployment Team meeting notes [4], you will see
> that what is suggested here (a scalable public shared network) is an
> objective we wish but are struggling hard to achieve.
>

There are many ways to skin this cat IMO, and scalable public shared
network can really have multiple meanings, I appreciate the pointers
nonetheless.


>
> People keep asking for simplicity and Neutron looks to not be able to
> offer it due to philosophical conflicts between Neutron developers and
> actual public users/operators. We can't force our users to adhere to ONE
> networking philosophy: use NAT, floating IPs, firewall, routers, etc.
> They just don't buy it. Period. (see monty's list of public providers
> attaching VMs to public network)
>

Public providers networking needs are not the only needs that Neutron tries
to gather. There's a balance to be struck, and I appreciate that the
balance may need to be adjusted, but being so dismissive is being myopic of
the entire industry landscape.


>
> If we can accept and agree that not everyone wishes to adhere to the
> "full stack of networking good practices" (TBH, I don't know how to call
> this thing), it will be a good start. Otherwise I feel we won't be able
> to achieve anything.
>
> What Monty is explaining and suggesting is something we (my team) have
> been struggling with for *years* and just didn't have bandwidth (we are
> operators, not developers) or public charisma to change.
>
> I'm glad Monty brought up this subject so we can officially address it.
>
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-July/070028.html
> [2]
>
> http://lists.openstack.org/pipermail/openstack-operators/2015-August/007857.html
> [3]
>
> http://specs.openstack.org/openstack/neutron-specs/specs/liberty/get-me-a-network.html
> [4]
>
> http://lists.openstack.org/pipermail/openstack-operators/2015-June/007427.html
>
> --
> Mathieu
>
> __________________________________________________________________________
> 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/e8b3b677/attachment.html>


More information about the OpenStack-dev mailing list