> -----Original Message----- > From: Hiroaki KAWAI [mailto:ka...@stratosphere.co.jp] > Sent: Wednesday, May 29, 2013 8:39 AM > To: Sheng Yang > Cc: Hugo Trippaers; cloudstack > Subject: Re: Review Request: CLOUDSTACK-2327: make cloud-setup-agent > ovs aware > > (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..
With brcomcat the linux bridge module must still be disabled. However the old bridge tools will still work but use the openvswitch underneath, it's really just a compatibility layer. > > > 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. That's tricky. I usually check if the openvswitch kernel module is loaded in the system, but it could be statically compile into the kernel. Using ovs-vsctl is also a possibility, but might hang if the database is not present and in general only reports if the userland binaries are installed. > > I'm ok for changing the default to ovs (adding dependency in packages). I'm fine with this too. I didn't do it for backwards compatibility and to prevent problems with existing setup. I think it's perfectly fine to make ovs the default with the next release. Then we have one release (4.1) where people can play with the ovs integration on KVM and in the next release it's enabled by default. However I think we should not force the installation of the openvswitch on users when we install cloudstack-agent. That is something that should be done by sysadmins. Just like we don't force the installation of kvm virtualization tools. However we should tell the user that openvswitch support is not enabled on the system and that it is a requirement. > >
