On 26/11/12 03:15, Shu Ming wrote: > Livnat, > > Thanks for your summary. I got comments below. > > 2012-11-25 18:53, Livnat Peer: >> Hi All, >> We have been discussing $subject for a while and I'd like to summarized >> what we agreed and disagreed on thus far. >> >> The way I see it there are two related discussions: >> >> >> 1. Getting VDSM networking stack to be distribution agnostic. >> - We are all in agreement that VDSM API should be generic enough to >> incorporate multiple implementation. (discussed on this thread: Alon's >> suggestion, Mark's patch for adding support for netcf etc.) >> >> - We would like to maintain at least one implementation as the >> working/up-to-date implementation for our users, this implementation >> should be distribution agnostic (as we all acknowledge this is an >> important goal for VDSM). >> I also think that with the agreement of this community we can choose to >> change our focus, from time to time, from one implementation to another >> as we see fit (today it can be OVS+netcf and in a few months we'll use >> the quantum based implementation if we agree it is better) >> >> 2. The second discussion is about persisting the network configuration >> on the host vs. dynamically retrieving it from a centralized location >> like the engine. Danken raised a concern that even if going with the >> dynamic approach the host should persist the management network >> configuration. > > About dynamical retrieving from a centralized location, when will the > retrieving start? Just in the very early stage of host booting before > network functions? Or after the host startup and in the normal running > state of the host? Before retrieving the configuration, how does the > host network connecting to the engine? I think we need a basic well > known network between hosts and the engine first. Then after the > retrieving, hosts should reconfigure the network for later management. > However, the timing to retrieve and reconfigure are challenging. >
We did not discuss the dynamic approach in details on the list so far and I think this is a good opportunity to start this discussion... From what was discussed previously I can say that the need for a well known network was raised by danken, it was referred to as the management network, this network would be used for pulling the full host network configuration from the centralized location, at this point the engine. About the timing for retrieving the configuration, there are several approaches. One of them was described by Alon, and I think he'll join this discussion and maybe put it in his own words, but the idea was to 'keep' the network synchronized at all times. When the host have communication channel to the engine and the engine detects there is a mismatch in the host configuration, the engine initiates 'apply network configuration' action on the host. Using this approach we'll have a single path of code to maintain and that would reduce code complexity and bugs - That's quoting Alon Bar Lev (Alon I hope I did not twisted your words/idea). On the other hand the above approach makes local tweaks on the host (done manually by the administrator) much harder. Any other approaches ? I'd like to add a more general question to the discussion what are the advantages of taking the dynamic approach? So far I collected two reasons: -It is a 'cleaner' design, removes complexity on VDSM code, easier to maintain going forward, and less bug prone (I agree with that one, as long as we keep the retrieving configuration mechanism/algorithm simple). -It adheres to the idea of having a stateless hypervisor - some more input on this point would be appreciated Any other advantages? discussing the benefits of having the persisted Livnat _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
