Open Stack

> On Apr 17, 2015, at 8:53 PM, Monty Taylor <mordred at inaugust.com> wrote:
> 
> On 04/17/2015 06:48 PM, Rochelle Grober wrote:
>> I know the DevStack issue seems to be solved, but I had to
>> respond.....inline
>> 
>> From: Fox, Kevin M [mailto:Kevin.Fox at pnnl.gov] Sent: Friday, April
>> 17, 2015 12:28 To: OpenStack Development Mailing List (not for usage
>> questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge
>> as the default in DevStack [was: Status of the nova-network to
>> Neutron migration work]
>> 
>> No, the complaints from ops I have heard even internally, which I
>> think is being echo'd here is "I understand how linux bridge works, I
>> don't opensvswitch". and "I don't want to be bothered to learn to
>> debug openvswitch because I don't think we need it".
>> 
>> If linux bridge had feature parity with openvswitch, then it would be
>> a reasonable argument or if the users truly didn't need the extra
>> features provided by openvswitch/naas. I still assert though, that
>> linux bridge won't get feature parity with openvswitch and the extra
>> features are actually critical to users (DVR/NaaS), so its worth
>> switching to opevnswitch and learning how to debug it. Linux Bridge
>> is a nonsolution at this point. 
> 
> I'm sorry, but with all due respect - I believe that sounds very much
> like sticking fingers in ears and not paying attention to the very real
> needs of users.
> 
> Let me tell you some non-features I encounter currently:
> 
> - Needing Floating IPs to get a public address
> 
> This is touted as "the right way to do it" - but it's actually a
> terrible experience for a user. The clouds I have access to that just
> give me a direct DHCP address are much more useful.

Is there a reason that neutron “provider” networks won’t work for you? That exact use case is covered, with neutron providing dhcp and metadata, and the underlying physical network doing everything else.  If that physical network is directly routable, so are your VMs. No need for fips or NAT.


> 
> In fact, we should delete floating ips - they are a non-feature that
> make life harder. Literally no user of a cloud has ever wanted them,
> although we've learned to deal with them.
> 
> - SDN
> 
> I understand this is important for people, so let's keep it around - but
> having software routers essentially means that it's a scaling
> bottleneck. In the cloud Infra uses that has SDN, we have to create
> multiple software routers to handle the scaling issues. On the other
> hand, direct routing / linuxbridge does NOT have this problem, because
> the network packets are routed directly.
> 
> We should not delete SDN like we should delete floating IPs, because
> there are real users who have real uses cases and SDN helps them.
> However, it should be an opt-in feature for a user that is an add on.
> 
> vexxhost is getting this right right now - you automatically get a
> DHCP'd direct routed IP on each VM you provision, but if you decide you
> need fancy, you can opt in to create a private network.

The SDN-lite tenant networks can co-exist with provider networks, so it’s not an either/or.

> 
> - DVR
> 
> I'm an end user. I do not care about this at all. DVR is only important
> if you have bought in to software routers. It's a solution to a problem
> that would go away if things worked like networks.

I don’t think this is even an issue if you’re not using neutron routers.

Thanks,
doug


> 
> 
> 
>> :/ So is keeping nova-network around
>> forever. :/ But other then requiring some more training for ops
>> folks, I think Neutron can suit the rest of the use cases these days
>> nova-network provided over neutron. The sooner we can put the
>> nova-network issue to bed, the better off the ecosystem will be. It
>> will take a couple of years for the ecosystem to settle out to
>> deprecating it, since a lot of clouds take years to upgrade and
>> finally put the issue to bed. Lets do that sooner rather then later
>> so a couple of years from now, we're done. :/
> 
> I'm about to deploy a cloud, I'm going to run neutron, and I'm not going
> to run openvswitch because I do not need it. I will run the equiv of
> flatdhcp.
> 
> If neutron doesn't have it, I will write it, because it's that important
> that it exist.
> 
> If you take that ability away from me, you will be removing working
> feature and replacing them with things that make my user experience worse.
> 
> Let's not do that. Let's listen to the people who are using this thing
> as end users. Let's understand their experience and frustration. And
> let's not chase pie-in-the-sky theory of how it "should" work in the
> face of what a ton of people are asking and even begging for. FlatDHCP
> is perfect for the 80% case. The extra complexity of the additional
> things if you don't actually need them is irresponsible.
> 
>> 
>> [Rockyg] Kevin, the problem is that the extra features *aren't*
>> critical to the deployers and/or users of many of openstack
>> deployments.  And since they are not critical, the deployers won't
>> *move* to using neutron that requires them to learn all this new
>> "stuff" that thjey don't need.  By not providing a simple path to a
>> flatDHCP implementation, you will get existing users refusing to
>> upgrade rather than take a bunch of extraneous stuff from Neutron
>> because the OpenStack project deprecated "their network." So, likely
>> two things will happen: 1) the deployments that are already you there
>> configured with nova-network and flatDHCP will stop upgrading with
>> the last nova-network release and 2) if there isn't a simple
>> equivalent by then in neutron or some other openstack project,
>> someone will fork to keep the flatDHCP solution moving forward.
>> 
>> You can lead a devops to pizza, but you can't make it eat soylent
>> green pizza.  And that's how you lose some of the community and
>> perhaps spur either Neutron's or OpenStack's successor open source
>> project(s).
>> 
>> KISS is still in effect.  It seems Neutron is abstracting away the
>> current network complexities for developers and endusers at the
>> expense of tossing it all on the shoulders of the deployer/admins.
>> Until you abstract some of that complexity out of the deployment
>> path, either through good coding, useful templates, configuration and
>> management tools, etc., you're going to continue to get pushback from
>> the devops and they will continue to claim parity doesn't exist *for
>> them*.
>> 
>> Something I learned a while ago - the sysadmins control the system
>> and stick with minor changes and/or single system by system upgrades
>> until they are either tempted with something
>> shiny/fun/cool/sexy/powerful or coerced by management to change.
>> Until you can demonstrate a *benefit* to them to move to the neutron
>> paradigm for their flatDHCP network, you won't get them to move.
>> They'll take a learning ramp-up, for either less work or better
>> control, but they won't take it for more work.
>> 
>> --Rocky
>> 
>> ________________________________ From: Kevin Benton
>> [blak111 at gmail.com] Sent: Friday, April 17, 2015 11:49 AM To:
>> OpenStack Development Mailing List (not for usage questions) Subject:
>> Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in
>> DevStack [was: Status of the nova-network to Neutron migration work] 
>> I definitely understand that. But what is the major complaint from
>> operators? I understood that quote to imply it was around Neutron's
>> model of self-service networking.
>> 
>> If the main reason the remaining Nova-net operators don't want to use
>> Neutron is due to the fact that they don't want to deal with the
>> Neutron API, swapping some implementation defaults isn't really going
>> to get us anywhere on that front.
>> 
>> It's an important distinction because it determines what actionable
>> items we can take (e.g. what Salvatore mentioned in his email about
>> defaults). Does that make sense?
>> 
>> On Fri, Apr 17, 2015 at 11:33 AM, Jeremy Stanley
>> <fungi at yuggoth.org<mailto:fungi at yuggoth.org>> wrote: On 2015-04-17
>> 10:55:19 -0700 (-0700), Kevin Benton wrote:
>>> I understand. What I'm saying is that switching to Linux bridge 
>>> will not change the networking model to 'just connect everything to
>>> a simple flat network'. All of the complaints about self-service
>>> networking will still hold.
>> 
>> And conversely, swapping simple bridge interfaces for something else 
>> still means problems are harder to debug, whether or not you're stuck
>> with self-service networking features you're not using. -- Jeremy
>> Stanley
>> 
>> __________________________________________________________________________
>> 
>> 
> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>> 
>> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> 
>> -- Kevin Benton
>> 
>> 
>> 
>> __________________________________________________________________________
>> 
>> 
> 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