On Wed, Nov 14, 2012 at 11:53:06AM +0200, Livnat Peer wrote:
> 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.
Adam Litke <a...@us.ibm.com>
IBM Linux Technology Center
vdsm-devel mailing list