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: Wednesday, February 27, 2013 11:14:35 AM
> Subject: Re: vdsm networking changes proposal
> 
> On Tue, Feb 26, 2013 at 10:51:12AM -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: 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.
> 
> Vdsm has to be aware of the underlying technologies, but this
> awareness
> has to be confined to two places:
>  - the providers.
>  - the thing that selects which provider should be used today.

I don't understand the 2nd item... why is 'today' important? and what is 'thing'?

> 
> > 
> > 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.
> 
> Sure.
> 
> Dan.
>