(2013/05/29 15:26), Sheng Yang wrote:
One more reason was to allow people use native bridging
even one has accidentally installed openvswitch package.
Bridge created on ovs is different from bridge created on native linux
bridge. For later, ovs-vsctl shouldn't show any bridge/switch(e.g.
cloudbr0), but brctl would. And I remember they're probably
exclusive(openvswitch kernel module vs bridge module)?
Without brcompat, brctl would not show ovs bridges.
bridge and openvswitch do coexist.
With brcompat, we must use exclusively, but brcompat
is obsolete now..
I think you're suggesting making it more few setup steps
for enabling ovs. And I completly agree with it. So we might
need some more improvements here...
In fact, I am thinking about preconfigured ovs environment(KVM or Xen).
I think openvswitch enabling shouldn't be part of work of
cloudstack(e.g. it's not a part of adding XenServer host). For KVM, user
can loaded openvswitch module(without brcompat module), unload bridge
module, and start openvswitch service to enable ovs. We should add some
steps in manual for that.
I am agree we need more investigation here, to find a proper way tell if
user want to use ovs or not.
I'm ok for changing the default to ovs (adding dependency in packages).
