[openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

Fox, Kevin M Kevin.Fox at pnnl.gov
Fri Apr 17 11:20:56 UTC 2015


Complex is kind of the wrong thing to describe the deployer complaint. Its learning curve. "To debug issues, I have to learn someting new, and I dont want to because I dont believe I need that feature". I get it. I really do. But there are three actors here, not just one. The deployer, the app developer, and the user... the deployer often doesnt but the user/developer does.

Im convinced OpenStack is a data center operating system. Linux has many parallels. The Linux sysadmin is the deployer, the userspace app developer is the OpenStack app developer, syscalls are rest api... The main odd difference in the parallel is that in Linux, you have to purposefully compile out major kernel subsystems, and in OpenStack, you must install them separately.

But think of it this way. What would you get if a third of the Linux population compiled out the unix pipe subsystem? That's the close parallel. Shell scripting changes drastically from something that looks like Unix, to something that looks like Windows pre Powershell. The whole development model for the app deployers changes. The same is true in OpenStack. You leave out naas, you end up with heat templates that are very different.

By not wanting to learn something new, the deployers are forcing the "complexity" of this fractured operating system target on the users (who should long term greatly outnumber deployers). The ecosystem the app developers create on top is worse off because they have to target the lowest common denominator.

In the end any Operating System lives or dies by the ecosystem of apps built on top of it. My opinion is the continued push for not supporting naas is weakining the ecosystem. We should make sure neutron will scale the way deployers need, then depricate nova-network. Making it too easy to gut large subsystems functionality too easily to cator to the deployers not wanting to learn something new will hurt everyone in the long run. Apps dont get written and the deployers have less reason to deploy due to lack of demand.

Lets focus on a strong OpenStack ecosystem.

Thanks,
Kevin

________________________________
From: Kevin Benton
Sent: Thursday, April 16, 2015 9:17:03 PM
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]


What do you disagree with? I was pointing out that using Linux bridge will not reduce the complexity of the model of self-service networking, which is what the quote was complaining about.

I just wanted to point out that one of the 'major disconnects' as I understand it will not get any better by switching drivers.

On 2015-04-16 18:34:40 -0700 (-0700), Kevin Benton wrote:
[...]
> This is referring to the complexity of the API model for Neutron.
> While this is a problem that I hope to address by making things
> like shared networks more useful, it's not really relevant to this
> particular discussion because the model complexity does not
> decrease with the switch to Linux bridge.

I disagree. Complexity for the operator includes more than the API.
It also includes troubleshooting what just went wrong when your
network decided to do a headstand. As a datapoint, compare the ease
of connecting tcpdump to a bridge interface vs the ease of
connecting tcpdump to an OVS instance.
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150417/ce337cc5/attachment.html>


More information about the OpenStack-dev mailing list