
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi all,</div><div class=""><br class=""></div>If I can attempt to summarize this thread:<div class=""><br class=""></div><div class="">“We want simple networks with VMs”</div><div class=""><br class=""></div><div class="">Ok, in progress, start here:</div><div class=""><br class=""></div><div class=""><a href="https://blueprints.launchpad.net/neutron/+spec/get-me-a-network" class="">https://blueprints.launchpad.net/neutron/+spec/get-me-a-network</a></div><div class=""><br class=""></div><div class="">“It should work with multiple networks”</div><div class=""><br class=""></div><div class="">Same spec, click above.</div><div class=""><br class=""></div><div class="">“It should work with just ‘nova boot’”</div><div class=""><br class=""></div><div class="">Yup, you guessed it, starting point is the same spec, click above.</div><div class=""><br class=""></div><div class="">“It should still work in the face of N-tiered ambiguity.”</div><div class=""><br class=""></div><div class="">Umm, how, exactly? I think if you have a super complicated setup, your boot might be a bit harder, too. Please look at the cases that are covered before getting upset, and then provide feedback on the spec.</div><div class=""><br class=""></div><div class="">“Networks should be accessible by name.”</div><div class=""><br class=""></div><div class="">Yup, if they don’t, it’s a bug. The client a few cycles ago was particularly bad at this. If you find more cases, please file a bug.</div><div class=""><br class=""></div><div class="">“Neutron doesn’t get it and never will.”</div><div class=""><br class=""></div><div class="">I’m not sure how all ‘yes’ above keeps translating to this old saw, but is there any tiny chance we can stop living in the past and instead focus on the use cases that we want to solve?</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">doug</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 15, 2015, at 5:44 PM, Armando M. <<a href="mailto:armamig@gmail.com" class="">armamig@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On 15 September 2015 at 15:11, Mathieu Gagné <span dir="ltr" class=""><<a href="mailto:mgagne@internap.com" target="_blank" class="">mgagne@internap.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2015-09-15 2:00 PM, Fox, Kevin M wrote:<br class="">

> We run several clouds where there are multiple external networks. the "just run it in on THE public network" doesn't work. :/<br class="">

><br class="">

> 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.<br class="">

><br class="">

<br class="">

</span>Sorry but I feel this kind of reply explains why people are still using<br class="">

nova-network over Neutron. People want simplicity and they are denied it<br class="">

at every corner because (I feel) Neutron thinks it knows better.<br class=""></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br class="">

The original statement by Monty Taylor is clear to me:<br class="">

<br class="">

I wish to boot an instance that is on a public network and reachable<br class="">

without madness.<br class="">

<br class="">

As of today, you can't unless you implement a deployer/provider specific<br class="">

solution (to scale said network). Just take a look at what actual public<br class="">

cloud providers are doing:<br class="">

<br class="">

- Rackspace has a "magic" public network<br class="">

- GoDaddy has custom code in their nova-scheduler (AFAIK)<br class="">

- iWeb (which I work for) has custom code in front of nova-api.<br class="">

<br class="">

We are all writing our own custom code to implement what (we feel)<br class="">

Neutron should be providing right off the bat.<br class=""></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br class="">

By reading the openstack-dev [1], openstack-operators [2] lists, Neutron<br class="">

specs [3] and the Large Deployment Team meeting notes [4], you will see<br class="">

that what is suggested here (a scalable public shared network) is an<br class="">

objective we wish but are struggling hard to achieve.<br class=""></blockquote><div class=""><br class=""></div><div class="">There are many ways to skin this cat IMO, and scalable public shared network can really have multiple meanings, I appreciate the pointers nonetheless.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br class="">

People keep asking for simplicity and Neutron looks to not be able to<br class="">

offer it due to philosophical conflicts between Neutron developers and<br class="">

actual public users/operators. We can't force our users to adhere to ONE<br class="">

networking philosophy: use NAT, floating IPs, firewall, routers, etc.<br class="">

They just don't buy it. Period. (see monty's list of public providers<br class="">

attaching VMs to public network)<br class=""></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br class="">

If we can accept and agree that not everyone wishes to adhere to the<br class="">

"full stack of networking good practices" (TBH, I don't know how to call<br class="">

this thing), it will be a good start. Otherwise I feel we won't be able<br class="">

to achieve anything.<br class="">

<br class="">

What Monty is explaining and suggesting is something we (my team) have<br class="">

been struggling with for *years* and just didn't have bandwidth (we are<br class="">

operators, not developers) or public charisma to change.<br class="">

<br class="">

I'm glad Monty brought up this subject so we can officially address it.<br class="">

<br class="">

<br class="">

[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-July/070028.html" rel="noreferrer" target="_blank" class="">http://lists.openstack.org/pipermail/openstack-dev/2015-July/070028.html</a><br class="">

[2]<br class="">

<a href="http://lists.openstack.org/pipermail/openstack-operators/2015-August/007857.html" rel="noreferrer" target="_blank" class="">http://lists.openstack.org/pipermail/openstack-operators/2015-August/007857.html</a><br class="">

[3]<br class="">

<a href="http://specs.openstack.org/openstack/neutron-specs/specs/liberty/get-me-a-network.html" rel="noreferrer" target="_blank" class="">http://specs.openstack.org/openstack/neutron-specs/specs/liberty/get-me-a-network.html</a><br class="">

[4]<br class="">

<a href="http://lists.openstack.org/pipermail/openstack-operators/2015-June/007427.html" rel="noreferrer" target="_blank" class="">http://lists.openstack.org/pipermail/openstack-operators/2015-June/007427.html</a><br class="">

<span class="HOEnZb"><font color="#888888" class=""><br class="">

--<br class="">

Mathieu<br class="">

</font></span><div class="HOEnZb"><div class="h5"><br class="">

__________________________________________________________________________<br class="">

OpenStack Development Mailing List (not for usage questions)<br class="">

Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="">

<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">

</div></div></blockquote></div><br class=""></div></div>

__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></div></blockquote></div><br class=""></div></body></html>