vdsm networking changes proposal

Wed Feb 27 14:22:10 UTC 2013

----- 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 2:02:48 PM
> Subject: Re: vdsm networking changes proposal
> 
> 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.
> 

I think that the settings of which provider to use for what technology is to be specified via configuration, vdsm should not hard code anything regarding specific provider behavior, technology or other.

The obligation of having a sane configuration is on the administrator (or the host-deploy automation).

This approach will ensure will will be able to support multiple configurations without releasing new versions of vdsm, or be able to support different provider layout per distribution or usage (development/production).

If vdsm is to be aware of specific provider behavior, this behavior should be exposed at the provider's interface.

Alon