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

Pavlin Radoslavov pavlin at icir.org
Thu Jun 1 18:54:49 PDT 2006


> > > 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.

I understand. Mike was already using nested modules, and my reply
was within the context of just getting the right order of the XRLs.

> 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.

I think you are right. I forgot about the bigger issue of taking
care of module dependencies. In fact, by looking into the sample
template with the nested module, the nested module inside
"interfaces" depends on "fea" and "static", so there is an
interesting dependency graph already.

Then, nested modules shouldn't be allowed, and the rtrmgr should
explicitly check for that.

Mike, it seems to me that you don't need to use nested modules for
what you want to achieve. First, decide whether you really need to
declare a new module (e.g., you might be able to achieve same thing
with the right %create, %update, %activate, etc. actions).
Only if you really need to declare a new module, then compose it
such that it doesn't overlap with other modules, and then declare
its dependencies as appropriate.

Pavlin



More information about the Xorp-hackers mailing list