Open Stack

I am not a neutron developer, but an operator and a writer of cloud apps.

Yes, it is sort of a philosophical issue, and I have stated my side of why I think the extra complexity is worth it. Feel free to disagree.

But either way I don't think we can ignore the complexity. There are three different ways to resolve it:

* Simple use case, no naas at all. The "simplest" solution, some app developers and some users suffer that actually need naas. users/app developers have to add it on top themselves.
* always naas. Ops (and perhaps users) have to deal with the extra complexity if they feel they don't need it. but its simpler in that you can always rely on it being there.
* No naas and naas are both supported. Ops get it easy. they pick which one they want, users suffer a little if they work on multiple clouds that differ. app developers suffer a lot since they have to write either two sets of software or pick the lowest common denominator.

Its an optimization problem. who do you shift the difficulty to?

My personal opinion again is that I'd rather suffer a little more as an Op and always deploy naas, rather then have to deal with the app developer pain of not being able to rely on it. The users/ops benefit the most if a strong app ecosystem can be developed on top.

Again, my personal opinion. Feel free to differ.

Thanks,
Kevin


________________________________________
From: Mathieu Gagné [mgagne at internap.com]
Sent: Tuesday, September 15, 2015 3:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

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.

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.

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.

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)

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