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

[Michael Larson]

OK--That makes sense that defining multiple modules at the same node results in an undefined order of execution. 

But, I don't see how this is different than allowing XRL's on the same node that are owned by different modules. The order of execution of the XRL's are undefined as well. For instance:

template file 1:

foo {
  bar {
    //module defined here within file 1
    zoo {
       %create: module_1_xrl_on_create
    }
  }
}

template file 2:

foo {
  //module defined here within file 2
  bar {
    zoo {
      %create: module_2_xrl_on_create
    }
  }
}

In the example above, which xrl should be executed first? I think the same question applies to modules declared on the same node.

In regards to the original issue I have found it useful to define a module on the same node as a previously defined xorp module (in this instance)--the main benefit being seperation of the source code.

Mike

----- Original Message -----
From: Pavlin Radoslavov <pavlin at icir.org>
To: Mark Handley <M.Handley at cs.ucl.ac.uk>
Cc: Michael Larson <mike at vyatta.com>, Pavlin Radoslavov <pavlin at icir.org>, xorp-hackers at icir.org
Sent: Thursday, June 1, 2006 6:54:49 PM GMT-0800
Subject: Re: [Xorp-hackers] transaction fix for nodes shared across modules

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

_______________________________________________
Xorp-hackers mailing list
Xorp-hackers at icir.org
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers