----- Original Message -----
From: "Dan Kenigsberg" <danken(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: "Antoni Segura Puimedon" <asegurap(a)redhat.com>,
vdsm-devel(a)fedorahosted.org, arch(a)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(a)redhat.com>
> > To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > Cc: "Antoni Segura Puimedon" <asegurap(a)redhat.com>,
> > vdsm-devel(a)fedorahosted.org, arch(a)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(a)redhat.com>
> > > > To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > > > Cc: "Antoni Segura Puimedon" <asegurap(a)redhat.com>,
> > > > vdsm-devel(a)fedorahosted.org, arch(a)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.