On Wed, Feb 27, 2013 at 06:06:30AM -0500, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
> > From: "Dan Kenigsberg" <dan...@redhat.com>
> > To: "Alon Bar-Lev" <alo...@redhat.com>
> > Cc: "Antoni Segura Puimedon" <asegu...@redhat.com>, 
> > vdsm-de...@fedorahosted.org, 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" <dan...@redhat.com>
> > > > To: "Alon Bar-Lev" <alo...@redhat.com>
> > > > Cc: "Antoni Segura Puimedon" <asegu...@redhat.com>,
> > > > vdsm-de...@fedorahosted.org, 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" <dan...@redhat.com>
> > > > > > To: "Alon Bar-Lev" <alo...@redhat.com>
> > > > > > Cc: "Antoni Segura Puimedon" <asegu...@redhat.com>,
> > > > > > vdsm-de...@fedorahosted.org, 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'?

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.
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to