Re: [vdsm] vdsm networking changes proposal
- Original Message - > From: "Dan Kenigsberg" > To: "Alon Bar-Lev" > Cc: "Antoni Segura Puimedon" , > vdsm-de...@fedorahosted.org, a...@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" > > > To: "Alon Bar-Lev" > > > Cc: "Antoni Segura Puimedon" , > > > 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" > > > > > To: "Alon Bar-Lev" > > > > > Cc: "Antoni Segura Puimedon" , > > > > > 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" > > > > > > > To: "Alon Bar-Lev" > > > > > > > Cc: "Antoni Segura Puimedon" , > > > > > > > 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 > > >
Re: [vdsm] vdsm networking changes proposal
On Wed, Feb 27, 2013 at 06:06:30AM -0500, Alon Bar-Lev wrote: > > > - Original Message - > > From: "Dan Kenigsberg" > > To: "Alon Bar-Lev" > > Cc: "Antoni Segura Puimedon" , > > 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" > > > > To: "Alon Bar-Lev" > > > > Cc: "Antoni Segura Puimedon" , > > > > 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" > > > > > > To: "Alon Bar-Lev" > > > > > > Cc: "Antoni Segura Puimedon" , > > > > > > 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 t
Re: [vdsm] vdsm networking changes proposal
- Original Message - > From: "Dan Kenigsberg" > To: "Alon Bar-Lev" > Cc: "Antoni Segura Puimedon" , > 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" > > > To: "Alon Bar-Lev" > > > Cc: "Antoni Segura Puimedon" , > > > 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" > > > > > To: "Alon Bar-Lev" > > > > > Cc: "Antoni Segura Puimedon" , > > > > > 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 th
Re: [vdsm] vdsm networking changes proposal
On Tue, Feb 26, 2013 at 10:51:12AM -0500, Alon Bar-Lev wrote: > > > - Original Message - > > From: "Dan Kenigsberg" > > To: "Alon Bar-Lev" > > Cc: "Antoni Segura Puimedon" , > > 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" > > > > To: "Alon Bar-Lev" > > > > Cc: "Antoni Segura Puimedon" , > > > > 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. > > 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. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel