Re: [vdsm] vdsm networking changes proposal

[David Jaša]

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?

David

>  
>  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(a)redhat.com&gt;
>  > To: arch(a)ovirt.org, vdsm-devel(a)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(a)ovirt.org
>  > http://lists.ovirt.org/mailman/listinfo/arch
>  > 
>  _______________________________________________
>  vdsm-devel mailing list
>  vdsm-devel(a)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