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

[Pavlin Radoslavov]

> 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

We cannot have same node partially owned by different modules.
In your example below you have done this by using nested modules.
It doesn't matter whether whether the nested modules are defined in
a single file or separate files.

As Mark pointed earlier, nested modules are problematic for other
reasons (module dependency, etc).

Pavlin

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