----- Original Message -----
From: "David Jaša" <djasa(a)redhat.com>
To: vdsm-devel(a)fedorahosted.org, arch(a)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(a)redhat.com>
> > 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
_______________________________________________
vdsm-devel mailing list
vdsm-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel