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?

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.

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" <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
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to