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.
> - iproute2 provider
> - ovs provider
> - ifcfg provider
> - iproute2
> - team
> - ovs
> - ifcfg
> - iproute2
> - ovs
> - ifcfg
> So we can get a configuration of:
> 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?
> 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.
> Alon Bar-Lev
> ----- Original Message -----
> > From: "Antoni Segura Puimedon" <asegu...@redhat.com>
> > To: a...@ovirt.org, vdsm-de...@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
> > a...@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> vdsm-devel mailing list
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