Sent from my iPhone
On 29 mei 2013, at 22:29, "Sheng Yang" <sh...@yasker.org<mailto:sh...@yasker.org>> wrote: On Wed, May 29, 2013 at 12:09 AM, Hugo Trippaers <htrippa...@schubergphilis.com<mailto:htrippa...@schubergphilis.com>> wrote: > -----Original Message----- > From: Hiroaki KAWAI > [mailto:ka...@stratosphere.co.jp<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. Actually you can :-(. This leads to all sorts of strange problems. Bridge and openvswitch can't coexist. > > > 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? It tries to open the database and keeps on trying for some time. I haven't checked the sources yet but it appears to keep trying for some time. > > 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... In terms of stability and scalability I'm not worried at all. I've met some of the guys working on it and the amount of work on performance is amazing. In xencenter it is working really well and we out did most of our performance benchmarks. Openvswitch is becoming a standard in many cloud implementations I think. If we integrate it completely now we will be ready for upcoming changes like vxlan etc. But I agree we need to understand it very well ourselves too. I'm using it on a daily basis now, but not everyone is. --Sheng > >
