<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
How will it help to have a flat network where all vms, not just the ones that need that scarce resource are on the same network consuming ips?<br>
<br>
Thanks,<br>
Kevin <strong>
<div><font face="Tahoma" color="#000000" size="2"> </font></div>
</strong>
<hr tabindex="-1">
<font face="Tahoma" size="2"><b>From:</b> Daniel Comnea<br>
<b>Sent:</b> Saturday, April 18, 2015 2:07:03 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]<br>
</font><br>
<div></div>
<div>
<div dir="ltr">Monty many thanks for a clear summary, fully agree with you. I have a nightmare trying to educate developers (mainly from client side) in my group that they need to get used with private net and not "consume" all
<span tabindex="-1" id=":3c2.1" class="" style="">FIP</span> because is not an unlimited resource<br>
<br>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Apr 18, 2015 at 3:53 AM, Monty Taylor <span dir="ltr">
<<a href="mailto:mordred@inaugust.com" target="_blank"><span tabindex="-1" id=":3c2.2" class="" style="">mordred</span>@<span tabindex="-1" id=":3c2.3" class="" style="">inaugust</span>.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<span class="">On 04/17/2015 06:48 PM, Rochelle Grober wrote:<br>
> I know the DevStack issue seems to be solved, but I had to<br>
</span>> respond.....inline<br>
<span class="">><br>
> From: Fox, Kevin M [mailto:<a href="mailto:Kevin.Fox@pnnl.gov">Kevin.Fox@pnnl.gov</a>] Sent: Friday, April<br>
> 17, 2015 12:28 To: OpenStack Development Mailing List (not for usage<br>
> questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge<br>
> as the default in DevStack [was: Status of the nova-network to<br>
> Neutron migration work]<br>
><br>
> No, the complaints from ops I have heard even internally, which I<br>
> think is being echo'd here is "I understand how linux bridge works, I<br>
> don't opensvswitch". and "I don't want to be bothered to learn to<br>
> debug openvswitch because I don't think we need it".<br>
><br>
> If linux bridge had feature parity with openvswitch, then it would be<br>
> a reasonable argument or if the users truly didn't need the extra<br>
> features provided by openvswitch/naas. I still assert though, that<br>
> linux bridge won't get feature parity with openvswitch and the extra<br>
> features are actually critical to users (DVR/NaaS), so its worth<br>
> switching to opevnswitch and learning how to debug it. Linux Bridge<br>
> is a nonsolution at this point.<br>
<br>
</span>I'm sorry, but with all due respect - I believe that sounds very much<br>
like sticking fingers in ears and not paying attention to the very real<br>
needs of users.<br>
<br>
Let me tell you some non-features I encounter currently:<br>
<br>
- Needing Floating IPs to get a public address<br>
<br>
This is touted as "the right way to do it" - but it's actually a<br>
terrible experience for a user. The clouds I have access to that just<br>
give me a direct DHCP address are much more useful.<br>
<br>
In fact, we should delete floating ips - they are a non-feature that<br>
make life harder. Literally no user of a cloud has ever wanted them,<br>
although we've learned to deal with them.<br>
<br>
- SDN<br>
<br>
I understand this is important for people, so let's keep it around - but<br>
having software routers essentially means that it's a scaling<br>
bottleneck. In the cloud Infra uses that has SDN, we have to create<br>
multiple software routers to handle the scaling issues. On the other<br>
hand, direct routing / linuxbridge does NOT have this problem, because<br>
the network packets are routed directly.<br>
<br>
We should not delete SDN like we should delete floating IPs, because<br>
there are real users who have real uses cases and SDN helps them.<br>
However, it should be an opt-in feature for a user that is an add on.<br>
<br>
vexxhost is getting this right right now - you automatically get a<br>
DHCP'd direct routed IP on each VM you provision, but if you decide you<br>
need fancy, you can opt in to create a private network.<br>
<br>
- DVR<br>
<br>
I'm an end user. I do not care about this at all. DVR is only important<br>
if you have bought in to software routers. It's a solution to a problem<br>
that would go away if things worked like networks.<br>
<span class=""><br>
<br>
<br>
>:/ So is keeping nova-network around<br>
> forever. :/ But other then requiring some more training for ops<br>
> folks, I think Neutron can suit the rest of the use cases these days<br>
> nova-network provided over neutron. The sooner we can put the<br>
> nova-network issue to bed, the better off the ecosystem will be. It<br>
> will take a couple of years for the ecosystem to settle out to<br>
> deprecating it, since a lot of clouds take years to upgrade and<br>
> finally put the issue to bed. Lets do that sooner rather then later<br>
> so a couple of years from now, we're done. :/<br>
<br>
</span>I'm about to deploy a cloud, I'm going to run neutron, and I'm not going<br>
to run openvswitch because I do not need it. I will run the equiv of<br>
flatdhcp.<br>
<br>
If neutron doesn't have it, I will write it, because it's that important<br>
that it exist.<br>
<br>
If you take that ability away from me, you will be removing working<br>
feature and replacing them with things that make my user experience worse.<br>
<br>
Let's not do that. Let's listen to the people who are using this thing<br>
as end users. Let's understand their experience and frustration. And<br>
let's not chase pie-in-the-sky theory of how it "should" work in the<br>
face of what a ton of people are asking and even begging for. FlatDHCP<br>
is perfect for the 80% case. The extra complexity of the additional<br>
things if you don't actually need them is irresponsible.<br>
<div>
<div class="h5"><br>
><br>
> [Rockyg] Kevin, the problem is that the extra features *aren't*<br>
> critical to the deployers and/or users of many of openstack<br>
> deployments. And since they are not critical, the deployers won't<br>
> *move* to using neutron that requires them to learn all this new<br>
> "stuff" that thjey don't need. By not providing a simple path to a<br>
> flatDHCP implementation, you will get existing users refusing to<br>
> upgrade rather than take a bunch of extraneous stuff from Neutron<br>
> because the OpenStack project deprecated "their network." So, likely<br>
> two things will happen: 1) the deployments that are already you there<br>
> configured with nova-network and flatDHCP will stop upgrading with<br>
> the last nova-network release and 2) if there isn't a simple<br>
> equivalent by then in neutron or some other openstack project,<br>
> someone will fork to keep the flatDHCP solution moving forward.<br>
><br>
> You can lead a devops to pizza, but you can't make it eat soylent<br>
> green pizza. And that's how you lose some of the community and<br>
> perhaps spur either Neutron's or OpenStack's successor open source<br>
> project(s).<br>
><br>
> KISS is still in effect. It seems Neutron is abstracting away the<br>
> current network complexities for developers and endusers at the<br>
> expense of tossing it all on the shoulders of the deployer/admins.<br>
> Until you abstract some of that complexity out of the deployment<br>
> path, either through good coding, useful templates, configuration and<br>
> management tools, etc., you're going to continue to get pushback from<br>
> the devops and they will continue to claim parity doesn't exist *for<br>
> them*.<br>
><br>
> Something I learned a while ago - the sysadmins control the system<br>
> and stick with minor changes and/or single system by system upgrades<br>
> until they are either tempted with something<br>
> shiny/fun/cool/sexy/powerful or coerced by management to change.<br>
> Until you can demonstrate a *benefit* to them to move to the neutron<br>
> paradigm for their flatDHCP network, you won't get them to move.<br>
> They'll take a learning ramp-up, for either less work or better<br>
> control, but they won't take it for more work.<br>
><br>
> --Rocky<br>
><br>
> ________________________________ From: Kevin Benton<br>
> [<a href="mailto:blak111@gmail.com">blak111@gmail.com</a>] Sent: Friday, April 17, 2015 11:49 AM To:<br>
> OpenStack Development Mailing List (not for usage questions) Subject:<br>
> Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in<br>
> DevStack [was: Status of the nova-network to Neutron migration work]<br>
> I definitely understand that. But what is the major complaint from<br>
> operators? I understood that quote to imply it was around Neutron's<br>
> model of self-service networking.<br>
><br>
> If the main reason the remaining Nova-net operators don't want to use<br>
> Neutron is due to the fact that they don't want to deal with the<br>
> Neutron API, swapping some implementation defaults isn't really going<br>
> to get us anywhere on that front.<br>
><br>
> It's an important distinction because it determines what actionable<br>
> items we can take (e.g. what Salvatore mentioned in his email about<br>
> defaults). Does that make sense?<br>
><br>
> On Fri, Apr 17, 2015 at 11:33 AM, Jeremy Stanley<br>
</div>
</div>
> <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a><mailto:<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>>> wrote: On 2015-04-17<br>
<span class="">> 10:55:19 -0700 (-0700), Kevin Benton wrote:<br>
>> I understand. What I'm saying is that switching to Linux bridge<br>
>> will not change the networking model to 'just connect everything to<br>
>> a simple flat network'. All of the complaints about self-service<br>
>> networking will still hold.<br>
><br>
> And conversely, swapping simple bridge interfaces for something else<br>
> still means problems are harder to debug, whether or not you're stuck<br>
> with self-service networking features you're not using. -- Jeremy<br>
> Stanley<br>
><br>
> __________________________________________________________________________<br>
><br>
><br>
OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
</span>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
<div class="HOEnZb">
<div class="h5">><br>
><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> -- Kevin Benton<br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
><br>
><br>
OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</body>
</html>