On Wed, Feb 27, 2013 at 06:06:30AM -0500, Alon Bar-Lev wrote: > > > ----- Original Message ----- > > From: "Dan Kenigsberg" <[email protected]> > > To: "Alon Bar-Lev" <[email protected]> > > Cc: "Antoni Segura Puimedon" <[email protected]>, > > [email protected], [email protected] > > 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" <[email protected]> > > > > To: "Alon Bar-Lev" <[email protected]> > > > > Cc: "Antoni Segura Puimedon" <[email protected]>, > > > > [email protected], [email protected] > > > > 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" <[email protected]> > > > > > > To: "Alon Bar-Lev" <[email protected]> > > > > > > Cc: "Antoni Segura Puimedon" <[email protected]>, > > > > > > [email protected], [email protected] > > > > > > 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. _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
