----- Original Message -----
> From: "Livnat Peer" <lp...@redhat.com>
> To: "Alon Bar-Lev" <alo...@redhat.com>
> Cc: vdsm-de...@fedorahosted.org
> Sent: Wednesday, November 14, 2012 11:53:06 AM
> Subject: Re: [vdsm] Future of Vdsm network configuration
> 
> On 14/11/12 00:28, Adam Litke wrote:
> > On Sun, Nov 11, 2012 at 09:46:43AM -0500, Alon Bar-Lev wrote:
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Dan Kenigsberg" <dan...@redhat.com>
> >>> To: vdsm-de...@fedorahosted.org
> >>> Sent: Sunday, November 11, 2012 4:07:30 PM
> >>> Subject: [vdsm] Future of Vdsm network configuration
> >>>
> >>> Hi,
> >>>
> >>> Nowadays, when vdsm receives the setupNetowrk verb, it mangles
> >>> /etc/sysconfig/network-scripts/ifcfg-* files and restarts the
> >>> network
> >>> service, so they are read by the responsible SysV service.
> >>>
> >>> This is very much Fedora-oriented, and not up with the new themes
> >>> in Linux network configuration. Since we want oVirt and Vdsm to
> >>> be
> >>> distribution agnostic, and support new features, we have to
> >>> change.
> >>>
> >>> setupNetwork is responsible for two different things:
> >>> (1) configure the host networking interfaces, and
> >>> (2) create virtual networks for guests and connect the to the
> >>> world
> >>> over (1).
> >>>
> >>> Functionality (2) is provided by building Linux software bridges,
> >>> and
> >>> vlan devices. I'd like to explore moving it to Open vSwitch,
> >>> which
> >>> would
> >>> enable a host of functionalities that we currently lack (e.g.
> >>> tunneling). One thing that worries me is the need to reimplement
> >>> our
> >>> config snapshot/recovery on ovs's database.
> >>>
> >>> As far as I know, ovs is unable to maintain host level parameters
> >>> of
> >>> interfaces (e.g. eth0's IPv4 address), so we need another
> >>> tool for functionality (1): either speak to NetworkManager
> >>> directly,
> >>> or
> >>> to use NetCF, via its libvirt virInterface* wrapper.
> >>>
> >>> I have minor worries about NetCF's breadth of testing and usage;
> >>> I
> >>> know
> >>> it is intended to be cross-platform, but unlike ovs, I am not
> >>> aware
> >>> of a
> >>> wide Debian usage thereof. On the other hand, its API is ready
> >>> for
> >>> vdsm's
> >>> usage for quite a while.
> >>>
> >>> NetworkManager has become ubiquitous, and we'd better integrate
> >>> with
> >>> it
> >>> better than our current setting of NM_CONTROLLED=no. But as DPB
> >>> tells
> >>> us,
> >>> https://lists.fedorahosted.org/pipermail/vdsm-devel/2012-November/001677.html
> >>> we'd better offload integration with NM to libvirt.
> >>>
> >>> We would like to take Network configuration in VDSM to the next
> >>> level
> >>> and make it distribution agnostic in addition for setting the
> >>> infrastructure for more advanced features to be used going
> >>> forward.
> >>> The path we think of taking is to integrate with OVS and for
> >>> feature
> >>> completeness use NetCF, via its libvirt virInterface* wrapper.
> >>> Any
> >>> comments or feedback on this proposal is welcomed.
> >>>
> >>> Thanks to the oVirt net team members who's input has helped
> >>> writing
> >>> this
> >>> email.
> >>
> >> Hi,
> >>
> >> As far as I see this, network manager is a monster that is a huge
> >> dependency
> >> to have just to create bridges or configure network interfaces...
> >> It is true
> >> that on a host where network manager lives it would be not polite
> >> to define
> >> network resources not via its interface, however I don't like we
> >> force network
> >> manager.
> >>
> >> libvirt is long not used as virtualization library but system
> >> management
> >> agent, I am not sure this is the best system agent I would have
> >> chosen.
> >>
> >> I think that all the terms and building blocks got lost in time...
> >> and the
> >> result integration became more and more complex.
> >>
> >> Stabilizing such multi-layered component environment is much
> >> harder than
> >> monolithic environment.
> >>
> >> I would really want to see vdsm as monolithic component with full
> >> control over
> >> its resources, I believe this is the only way vdsm can be stable
> >> enough to be
> >> production grade.
> >>
> >> Hypervisor should be a total slave of manager (or cluster), so I
> >> have no
> >> problem in bypassing/disabling any distribution specific tool in
> >> favour of
> >> atoms (brctl, iproute), in non persistence mode.
> >>
> >> I know this derive some more work, but I don't think it is that
> >> complex to
> >> implement and maintain.
> >>
> >> Just my 2 cents...
> > 
> > I couldn't disagree more.  What you are suggesting requires that we
> > reimplement
> > every single networking feature in oVirt by ourselves.  If we want
> > to support
> > the (absolutely critical) goal of being distro agnostic, then we
> > need to
> > implement the same functionality across multiple distros too.  This
> > is more work
> > than we will ever be able to keep up with.  If you think it's hard
> > to stabilize
> > the integration of an external networking library, imagine how hard
> > it will be
> > to stabilize our own rewritten and buggy version.  This is not how
> > open source
> > is supposed to work.  We should be assembling distinct, modular,
> > pre-existing
> > components together when they are available.  If NetworkManager has
> > integration
> > problems, let's work upstream to fix them.  If it's dependencies
> > are too great,
> > let's modularize it so we don't need to ship the parts that we
> > don't need.
> > 
> 
> I agree with Adam on this one, reimplementing the networking
> management
> layer by ourselves using only atoms seems like duplication of work
> that
> was already done and available for our use both by NM and by libvirt.
> 
> Yes, it is not perfect (far from it actually) but I think we better
> focus our efforts around adding new functionalities to VDSM and
> improving the current robustness of the code (we have issues
> regardless
> of any external component we're using).
> 
> For the sake of being distribution agnostic I support the original
> plan
> proposed by danken, using OVS combined with libvirt virInterface*
> wrapper.
> 
> 

Agree, +1

> Livnat
> 
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to