On Wed, May 29, 2013 at 12:09 AM, Hugo Trippaers < htrippa...@schubergphilis.com> wrote:
> > > > -----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. > If they're able to coexisted(no brcompat module), then we should able to look into both ovs-vsctl(if it's not hang...) and brctl, to find the bridge user want to program. I don't think user can configure e.g. cloudbr0 on the both. > > > > > 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 think "ovs-vsctl show"should report error if db is not existed rather than hang? > > > > > 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. > Agree on not install automatically. Admin should do that. But change default to ovs seems a big step for now, we didn't know enough of ovs I think, e.g. scalability, stability. I think it would need more time... --Sheng > > > > > > >
