I know the DevStack issue seems to be solved, but I had to respond.....inline

From: Fox, Kevin M [mailto:kevin....@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. :/ 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. :/

Kevin

[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 [blak...@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 
<fu...@yuggoth.org<mailto:fu...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to