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.


Obviously the second discussion influences the API modeling. Since I
think it would be challenging to add support for generic API and change
the current implementation to match the dynamic configuration approach
simultaneously I suggest we'll focus our efforts on one change at a time.

I suggest to have a discussion on the pro's and con's of dynamic
configuration and after we get to a consensus around that we can start
modeling the generic API.

thoughts? comments?

Livnat
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to