cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sheng Yang <sh...@yasker.org>
Subject Re: Review Request: CLOUDSTACK-2327: make cloud-setup-agent ovs aware
Date Wed, 29 May 2013 20:29:35 GMT
On Wed, May 29, 2013 at 12:09 AM, Hugo Trippaers <
HTrippaers@schubergphilis.com> wrote:

>
>
> > -----Original Message-----
> > From: Hiroaki KAWAI [mailto:kawai@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

>
> >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message