On 16/04/15 10:54, Fox, Kevin M wrote:
Yes, but.... if stuff like dvr is the only viable replacement to
nova-network in production, then learning the non representitive config
of neutron with linuxbridge might be misleading/counter productive since
ovs looks very very different.
Sure, though on the other hand, doesn't current discussion seem to
indicate that OVS with DVR is not a viable replacement for nova-network
multi-host HA (eg due to complexity), and this is why folks were working
towards linux bridge?
In essence: if linux bridge was a viable nova-network multi-host HA
replacement, you'd be OK with this change?
Kevin *
*
------------------------------------------------------------------------
*From:* Tom Fifield
*Sent:* Wednesday, April 15, 2015 5:58:43 PM
*To:* openstack-dev@lists.openstack.org
*Subject:* Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the
default in DevStack [was: Status of the nova-network to Neutron
migration work]
On 14/04/15 23:36, Dean Troyer wrote:
On Tue, Apr 14, 2015 at 7:02 AM, Miguel Angel Ajo Pelayo
<mangel...@redhat.com <mailto:mangel...@redhat.com>> wrote:
Why would operators install from devstack? that’s not going to be
the case.
If they do they need more help than we can give...
So, ummm, there is actually a valid use case for ops on devstack: it's
part of the learning process.
In my rounds, I've had feedback from more than a few whose first
OpenStack experience was to run up a devstack, so they could run ps
aufx, brctl, iptables, etc just to see what was going on under the
covers before moving on to something more 'proper'.
While acknowledging that the primary purpose and audience of devstack is
and should remain development and developers, if there is something we
can do to improve the experience for those ops first-timers that doesn't
have a huge impact on devs, it would be kinda nice.
After all, one of the reasons this thread exists is because of problems
with that ramp up process, no?
I believe we should have both LB & OVS well tested, if LB is a good
option for
some operators willing to migrate from nova, that’s great, let’s
make sure LB
is perfectly tested upstream.
+1
But by doing such change we can’t let OVS code rot and we would be
neglecting
a big customer base which is now making use of the openvswitch
mechanism.
(may be I’m miss understanding the scope of the change).
Changing DevStack's default doesn't remove anything OVS-related, nor
does it by itself remove any OVS jobs. It gives everyone who is happy
with nova-net (or more correctly doesn't think about it) a new default
that changes their experience the least for when nova-net disappears.
dt
--
Dean Troyer
dtro...@gmail.com <mailto:dtro...@gmail.com>
__________________________________________________________________________
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
__________________________________________________________________________
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
__________________________________________________________________________
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
__________________________________________________________________________
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
