On Wed, May 29, 2013 at 2:59 PM, Hugo Trippaers < htrippa...@schubergphilis.com> wrote:
> > > Sent from my iPhone > > On 29 mei 2013, at 22:29, "Sheng Yang" <sh...@yasker.org> wrote: > > 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. > > > Actually you can :-(. This leads to all sorts of strange problems. Bridge > and openvswitch can't coexist. > I tried, brctl reported error, since "cloudbr0" should be a interface name that won't allow duplicate: root@yasker-box1:~# ovs-vsctl show 02281b72-131c-4b24-b191-fb1bb7fe186d Bridge "cloudbr0" Port "eth0" Interface "eth0" Port "cloudbr0" Interface "cloudbr0" type: internal Bridge "cloud0" Port "cloud0" Interface "cloud0" type: internal ovs_version: "1.9.0" root@yasker-box1:~# brctl show bridge name bridge id STP enabled interfaces root@yasker-box1:~# brctl addbr cloudbr0 device cloudbr0 already exists; can't create bridge with the same name > > >> > >> > > 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. > Seems --no-wait can help? > >> > >> > 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. > Agree, I've switched to ovs as well. --Sheng > > > --Sheng > >> >> > >> > >> >> >
