[vdsm] Future of Vdsm network configuration - Thread mid-summary
Alon Bar-Lev
alonbl at redhat.com
Tue Nov 27 08:53:56 UTC 2012
----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Adam Litke" <agl at us.ibm.com>
> Cc: "Alon Bar-Lev" <abarlev at redhat.com>, "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>
> Sent: Tuesday, November 27, 2012 10:42:00 AM
> Subject: Re: [vdsm] Future of Vdsm network configuration - Thread mid-summary
>
> On 26/11/12 16:59, Adam Litke wrote:
> > On Mon, Nov 26, 2012 at 02:57:19PM +0200, Livnat Peer wrote:
> >> 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.
> >
> > I worry a lot about the above if we take the dynamic approach. It
> > seems we'd
> > need to introduce before/after 'apply network configuration' hooks
> > where the
> > admin could add custom config commands that aren't yet modeled by
> > engine.
> >
>
> yes, and I'm not sure the administrators would like the fact that we
> are
> 'forcing' them to write everything in a script and getting familiar
> with
> VDSM hooking mechanism (which in some cases require the use of custom
> properties on the engine level) instead of running a simple command
> line.
In which case will we force? Please be more specific.
If we can pass most of the iproute2, brctl, bond parameters via key/value pairs via the API, what in your view that is common or even seldom should be used?
This hook mechanism is only as fallback, provided to calm people down.
>
> >> Any other approaches ?
> >
> > Static configuration has the advantage of allowing a host to bring
> > itself back
> > online independent of the engine. This is also useful for anyone
> > who may want
> > to deploy a vdsm node in standalone mode.
> >
> > I think it would be possible to easily support a quasi-static
> > configuration mode
> > simply by extending the design of the dynamic approach slightly.
> > In dynamic
> > mode, the network configuration is passed down as a well-defined
> > data structure.
> > When a particular configuration has been committed, vdsm could
> > write a copy of
> > that configuration data structure to
> > /var/run/vdsm/network-config.json. During
> > a subsequent boot, if the engine cannot be contacted after
> > activating the
> > management network, the cached configuration can be applied using
> > the same code
> > as for dynamic mode. We'd have to flesh out the circumstances
> > under which this
> > would happen.
>
> I like this approach a lot but we need to consider that network
> configuration is an accumulated state, for example -
>
> 1. The engine sends a setup-network command with the full host
> network
> configuration
> 2. The user configures new network on the host, the engine sends a
> new
> setup-network request to VDSM which includes only the delta requested
> by
> the user (adding the required network)
> 3. VDSM adds the new network
THIS IS COMPLEX!!!!!!!
Almost AI.
As you need to complete the network setting with what you know.
> and this can go on and on, for dealing with this issue:
>
> We can either hold network-config.json per setup-network command and
> then for recovering the network configuration state we need to
> execute
> chain of set-up networks commands.
>
> Or we can move the logic of calculating the delta from engine to VDSM
> and on each setup network have the engine pass the full
> configuration.
> The problem with that approach is that the analysis logic of the
> delta
> has to be done on the engine anyway to give a quick feedback to the
> user
> on the validity of his action.
> Maintaining this logic/code twice is not something we want (it's bad
> enough to do it once....)
I don't understand how the two algorithm are the same...
UI is much more/less verbose at different aspects, while taking the full configuration and convert to actual setting is a completely different sequence.
What the feedback of the user? as far as I understand the user is only interested in the end-result... building his own network and expect it to be applied.
> A third option is to extend the current API of setup network to
> include
> the full configuration in addition to the delta that is sent today.
> The
> full configuration would be used for creating network-config.json and
> for that alone, VDSM would change network configuration according to
> the
> delta sent as it does today.
Always pass full configuration, why deal with two cases?
> The problem with that approach is that I'm sure someone on the list
> would say it is a contamination to the API, and we should 'never'
> pass
> 'duplicate' information. Personally I find this option the easiest
> one
> to deal with the above issue.
>
Livnat, I don't see any argument of persistence vs non persistence as the above is common to any approach taken.
Only this "manual configuration" argument keeps poping, which as I wrote is irrelevant in large scale and we do want to go into large scale.
Alon
>
> Livnat
>
> >
> >>
> >> 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
> >
> > As I mentioned above, the main benefit I see of having some sort of
> > persistent
> > configuration is:
> >
> > - To allow the host to operate independently of the engine in
> > either a failure
> > scenario or in a standalone configuration.
> >
>
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>
More information about the vdsm-devel
mailing list