vdsm networking changes proposal

[Dan Kenigsberg]

On Wed, Feb 27, 2013 at 06:06:30AM -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: 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'?

It's not really difficult, nor important, but let me try again.

Assume we have code of two providers for bridge. One is ifcfg-based, the
other is ovs-based. That's item 1.

Now we get a command to create a bridge. We do not intend to change the
API to let Engine select which of the two providers should be used, so
it is vdsm's obligation. That's item 2.