----- Original Message -----
> From: "Dan Kenigsberg" <dan...@redhat.com>
> To: "Mark Wu" <wu...@linux.vnet.ibm.com>
> Cc: a...@ovirt.org, vdsm-de...@fedorahosted.org
> Sent: Monday, February 25, 2013 12:49:19 PM
> Subject: Re: [vdsm] vdsm networking changes proposal
> On Thu, Feb 21, 2013 at 05:55:45PM +0800, Mark Wu wrote:
> > On Thu 21 Feb 2013 04:46:16 PM CST, Mark Wu wrote:
> > >On 02/18/2013 05:23 PM, David Jaša wrote:
> > Sorry for coming to it so late.
> Happy new year!
> > I get the following comments and questions about the proposal.
> > I suggest to add a field of top interface to the network, and only
> > apply IpConfig and mtu to it.
> I'm not sure how such an added field would help. Isn't the info
> available within the stucture of interface objects? Or do you suggest
> read-only field? I'd appreciate more details.
> > For the openvswitch configurator, it needs assistance of iproute2
> > because it can't configure ip/netmask/gw and mtu.
> Thanks, added to wiki.
> > I can't figure out the point to allow different configurators
> > except
> > openvswitch coexist. It could cause unnecessary complexity.
> I agree that we should decide on a very limited set of valid
> configurator combinations.
> > In the proposal, the rollback mechanism can be used to persist
> > configuration for iproute2. Why do we still need NetworkManager?
> We may need NetworkManager. It is present and running by default on
> target platforms -- inlcuding my laptop -- and it can be a bit rude
> other services that try to configure network devices not through it.
Maybe the reason to have NetworkManager provider is for pure debug/development
purposes, so you can run it on your laptop.
I think that as go forward we [might] see that the considerations for
hypervisors out-ways these of the desktop distribution.
> > I think the solution of "iproute2 + openvswitch + serializing
> > configuration objects" can meet all our requirements. I remember
> > that Dan had a concern of
> > adding a new standard about it in previous discussion. Have we
> > already get agreement on it?
> Well, I'd say that I've caved in. I see no other way forward without
> introducing our own form of persisting network definitions. At least
> keep our current setupNetworks API for that.
> vdsm-devel mailing list
vdsm-devel mailing list