[Xorp-hackers] transaction fix for nodes shared across modules

[Mark Handley]

On 6/1/06, Pavlin Radoslavov <pavlin at icir.org> wrote:
> > If a user creates an interface (with vrrp):
> >
> > >create interfaces ethernet eth0 vrrp virtual-address 1.1.1.1
> >
> > So that that both the modules interfaces and rl_interfaces are
> > created. Both these modules specify transactions, and within the
> > context of the ethernet node the transactions look like:
> >
> > start_transaction (interfaces)
> > restore-original-config-on-shutdown
> > commit_transaction (interfaces)
> >
> > start_transaction (rl_interfaces)
> > create_interface
> > set_interface_enabled
> > create_vif
> > set_vif_enabled
> > commit_transaction (rl_interfaces)
>
> With your modification, what is the ordering of the XRLs. Is it
> something like the following:
>
> ====
> start_transaction (interfaces)
> restore-original-config-on-shutdown
>
> start_transaction (rl_interfaces)
> create_interface
> set_interface_enabled
> create_vif
> set_vif_enabled
> commit_transaction (rl_interfaces)
>
> commit_transaction (interfaces)
> ====
>
> If the %modinfo definitions are nested, then I believe the
> start/commit transactions should also be nested.

This was not the design.

The router manager will figure out the entire set of XRLs to call,
then it will re-order them so that all the XRLs on one module are
called before starting the XRLs on any other module.  The order of
modules is determined by the dependencies specified in the template
files.  If there are two modules and no direct or indirect dependency
between them that determines their order, then the order of those two
is arbitrary.

I strongly believe that this is still the right solution -
interleaving XRLs between two or more modules makes it pretty much
impossible to reason about the dependencies, and makes it awfully hard
to know what should be configured before what when two modules are
changed together. Basically you can't end up with one module
half-configured and have another module then try to be reconfigured
and as a result talk to the first module and hit it in the
half-configured state.  You just don't want to go down that track -
too many race conditions and too much non-determinism.

 - Mark