----- 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'? > > > > > 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. > _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
