I'm late to the party as usual...

I'm all for dynamic set up of hosts, I think it's the only way to go. I don't 
understand how it can work anyway else.

That being said, if everything is set up dynamically it doesn't matter what 
backend we use to set it up as long as we can query the state.
We can even mix and match. Or am I missing something.

----- Original Message -----
> From: "Gary Kotton" <gkot...@redhat.com>
> To: vdsm-devel@lists.fedorahosted.org
> Sent: Wednesday, November 14, 2012 6:53:56 AM
> Subject: Re: [vdsm] Future of Vdsm network configuration
> 
> On 11/14/2012 11:53 AM, 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.
> 
> The addition of OVS is nice and refreshing (it is the new black). The
> issue with OVS is that a controller is required, there are a number
> of
> proprietary once and there are open source solutions.
> Something/someone
> needs to configure and manage the OVS. Just adding the libvirt
> support
> is not enough - in a nut shell this is just a matter of setting the
> network type for the vnic and passing a few additional parameters.
> Managing and assigning physical NICs to OVS is interesting and
> challenging. Do you guys have any thoughts about how you want to go
> about this?
> 
> Thanks
> Gary
> 
> 
> >
> >
> > 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
> 
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to