[vdsm] vdsm networking changes proposal

[Alon Bar-Lev]

----- Original Message -----
> From: "David Jaša" <djasa at redhat.com>
> To: vdsm-devel at fedorahosted.org, arch at ovirt.org
> Sent: Monday, February 18, 2013 11:23:21 AM
> Subject: Re: [vdsm] vdsm networking changes proposal
> 
> Hi,
> 
> Alon Bar-Lev píše v Ne 17. 02. 2013 v 15:57 -0500:
> > 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 don't quite understand the 'Team' configurator, are you
> > suggesting a provider for each technology?
> 
> Team is a new implementation of bonding in Linux kernel IIRC.
> 
> > 
> > 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 also would like us to explore a future alternative of the network
> > configuration via crypto vpn directly from qemu to another qemu,
> > the idea is to have a kerberos like key per layer3(or layer2)
> > destination, while communication is encrypted at user space and
> > sent to a flat network. The advantage of this is that we manage
> > logical network and not physical network, while relaying on
> > hardware to find the best route to destination. The question is
> > how and if we can provide this via the suggestion abstraction. But
> > maybe it is too soon to address this kind of future.
> 
> Isn't it better to separate the two goals and persuade qemu
> developers to implement TLS for migration connections?

Sure :)
But someone/something will need to configure it... :)

> 
> > 
> > For the open questions:
> > 
> > 1. Yes, I think that mode should be non-persistence, persistence
> > providers should emulate non-persistence operations by diff
> > between what they have and the goal.
> > 
> > 2. Once vdsm is installed, the mode it runs should be fixed. So the
> > only question is what is the selected profile during host
> > deployment.
> > 
> > 3. I think that if we can avoid aliases it would be nice.
> > 
> > 4. Keeping the least persistence information would be flexible. I
> > would love to see a zero persistence mode available, for example
> > if management interface is dhcp or manually configured.
> > 
> > I am very fond of the iproute2 configuration, and don't mind if
> > administrator configures the management interface manually. I
> > think this can supersede the ifcfg quite easily in most cases. In
> > these rare cases administrator use ovirt to modify the network
> > interface we may consider delegating persistence to totally
> > different model. But as far as I understand the problem is solely
> > related to the management connectivity, so we can implement a
> > simple bootstrap of non-persistence module to reconstruct the
> > management network setup from vdsm configuration instead of
> > persisting it to the distribution width configuration.
> > 
> > Regards,
> > Alon Bar-Lev
> > 
> > ----- Original Message -----
> > > From: "Antoni Segura Puimedon" <asegurap at redhat.com>
> > > To: arch at ovirt.org, vdsm-devel at fedorahosted.org
> > > Sent: Friday, February 8, 2013 12:54:23 AM
> > > Subject: vdsm networking changes proposal
> > > 
> > > Hi fellow oVirters!
> > > 
> > > The network team and a few others have toyed in the past with
> > > several
> > > important
> > > changes like using open vSwitch, talking D-BUS to NM, making the
> > > network
> > > non-persistent, etc.
> > > 
> > > It is with some of this changes in mind that we (special thanks
> > > go to
> > > Livnat
> > > Peer, Dan Kenigsberg and Igor Lvovsky) have worked in a proposal
> > > for
> > > a new architecture for vdsm's networking part. This proposal is
> > > intended to
> > > make our software more adaptable to new components and use cases,
> > > eliminate
> > > distro dependancies as much as possible and improve the
> > > responsiveness and
> > > scalability of the networking operations.
> > > 
> > > To do so, it proposes an object oriented representation of the
> > > different
> > > elements that come into play in our networking use cases.
> > > 
> > > But enough of introduction, please go to the feature page that we
> > > have put
> > > together and help us with your feedback, questions proposals and
> > > extensions.
> > > 
> > > http://www.ovirt.org/Feature/NetworkReloaded
> > > 
> > > 
> > > Best regards,
> > > 
> > > Toni
> > > _______________________________________________
> > > Arch mailing list
> > > Arch at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/arch
> > > 
> > _______________________________________________
> > vdsm-devel mailing list
> > vdsm-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 
> --
> 
> David Jaša, RHCE
> 
> SPICE QE based in Brno
> GPG Key:     22C33E24
> Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
> 
> 
> 
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>