vdsm networking changes proposal

[Alon Bar-Lev]

----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Antoni Segura Puimedon" <asegurap at redhat.com>, vdsm-devel at fedorahosted.org, arch at ovirt.org
> Sent: Tuesday, February 26, 2013 5:45:50 PM
> Subject: Re: vdsm networking changes proposal
> 
> On Tue, Feb 26, 2013 at 10:11:46AM -0500, Alon Bar-Lev wrote:
> > 
> > 
> > ----- Original Message -----
> > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "Antoni Segura Puimedon" <asegurap at redhat.com>,
> > > vdsm-devel at fedorahosted.org, arch at ovirt.org
> > > Sent: Monday, February 25, 2013 12:34:46 PM
> > > Subject: Re: vdsm networking changes proposal
> > > 
> > > On Sun, Feb 17, 2013 at 03:57:33PM -0500, Alon Bar-Lev wrote:
> > > > Hello Antoni,
> > > > 
> > > > Great work!
> > > > I am very excited we are going this route, it is first of many
> > > > to
> > > > allow us to be run on different distributions.
> > > > I apologize I got to this so late.
> > > > 
> > > > Notes for the model, I am unsure if someone already noted.
> > > > 
> > > > I think that the abstraction should be more than entity and
> > > > properties.
> > > > 
> > > > For example:
> > > > 
> > > > nic is a network interface
> > > > bridge is a network interface and ports network interfaces
> > > > bound is a network interface and slave network interfaces
> > > > vlan is a network interface and vlan id
> > > > 
> > > > network interface can have:
> > > > - name
> > > > - ip config
> > > > - state
> > > > - mtu
> > > > 
> > > > this way it would be easier to share common code that handle
> > > > pure
> > > > interfaces.
> > > 
> > > I agree with you - even though OOD is falling out of fashion in
> > > certain
> > > circles.
> > 
> > If we develop software like dressing fashion, we end up with
> > software working for a single season.
> > 
> > > 
> > > > 
> > > > I don't quite understand the 'Team' configurator, are you
> > > > suggesting a
> > > > provider for each technology?
> > > 
> > > Just as we may decide to move away from standard linux bridge to
> > > ovs-based bridging, we may switch from bonding to teaming. I do
> > > not
> > > think that we should do it now, but make sure that the design
> > > accomodates this.
> > 
> > So there should a separate provider for each object type, unless I
> > am missing something.
> > 
> > > > 
> > > > bridge
> > > > - iproute2 provider
> > > > - ovs provider
> > > > - ifcfg provider
> > > > 
> > > > bond
> > > > - iproute2
> > > > - team
> > > > - ovs
> > > > - ifcfg
> > > > 
> > > > vlan
> > > > - iproute2
> > > > - ovs
> > > > - ifcfg
> > > > 
> > > > So we can get a configuration of:
> > > > bridge:iproute2
> > > > bond:team
> > > > vlan:ovs
> > > 
> > > I do not think that such complex combinations are of real
> > > interest.
> > > The
> > > client should not (currently) be allowed to request them. Some
> > > say
> > > that
> > > the specific combination that is used by Vdsm to implement the
> > > network
> > > should be defined in a config file. I think that a python file is
> > > good
> > > enough for that, at least for now.
> > 
> > I completely lost you, and how it got to do with python nor file.
> > 
> > If we have implementation of iproute2 that does bridge, vlan, bond,
> > but we like to use ovs for bridge and vlan, how can we reuse the
> > iproute2 provider for the bond?
> > 
> > If we register provider per object type we may allow easier reuse.
> 
> Yes, this is the plan. However I do not think it is wise to support
> all
> conceivable combinations of provider/object. A fixed one, such as
> "ovs
> for bridge and vlan, iproute2 for bond" is good enough.

The whole point of the abstraction/provider thing is to vdsm *NOT* be aware of the underline technologies. I would not like to see 'if ovs then' or any other similar one in vdsm code after we have this mechanism in place.

Not that I say that a total generic sequence will require to work, but the ovs for bridge and vlan should be compatible with iproute for bond, while iproute for bridge and iproute for vlan and iproute for bond are compatible as well.

> > 
> > This, however, does not imply that the implementation is in python
> > (oh
> > well...) nor if the implementation is single file or multiple
> > file...
> 
> > 
> > > > 
> > > > ?
> > > > 
> > > > I also would like us to explore a future alternative of the
> > > > network
> > > > configuration via crypto vpn directly from qemu to another
> > > > qemu,
> > > > the
> > > > idea is to have a kerberos like key per layer3(or layer2)
> > > > destination,
> > > > while communication is encrypted at user space and sent to a
> > > > flat
> > > > network. The advantage of this is that we manage logical
> > > > network
> > > > and
> > > > not physical network, while relaying on hardware to find the
> > > > best
> > > > route to destination. The question is how and if we can provide
> > > > this
> > > > via the suggestion abstraction. But maybe it is too soon to
> > > > address
> > > > this kind of future.
> > > 
> > > This is something completely different, as we say in Python.
> > > The nice thing about your idea, is that in the context of host
> > > network
> > > configuration we need nothing more than our current
> > > bridge-bond-nic.
> > > The sad  thing about your idea, is that it would scale badly with
> > > the
> > > nubmer of virtual networks. If a new VM comes live and sends an
> > > ARP
> > > who-has broadcast message - which VMs should be bothered to
> > > attempt
> > > to
> > > decrypt it?
> > 
> > This is easily filtered by a tag. Just like in MPLS.
> 
> How is it different from a vlan tag, then? Or that you suggest that
> we
> trust qemu to do the tagging, instead of the host kernel?

I think that like MPLS, there will be vlan emulation server that qemu will register into.
But I think I am way ahead of this specific discussion.

Alon