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

[Michael Larson]

Pavlin comments below:

Mike

----- Original Message -----
From: Pavlin Radoslavov <pavlin at icir.org>
To: Michael Larson <mike at vyatta.com>
Cc: Pavlin Radoslavov <pavlin at icir.org>, xorp-hackers at icir.org
Sent: Thursday, June 1, 2006 2:00:06 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)
====

ML> In debug print statements the transactions were not nested but sequential--with the interfaces transaction closing before the rl_interfaces transaction started. So more along the lines of the following:

start_transaction (interfaces)
restore-original-config-on-shutdown
commit_transtion (interfaces)

start_transaction (rl_interfaces)
create_interface
set_interface_enabled
create_vif
set_vif_enabled
commit_transaction (rl_interfaces)


If the %modinfo definitions are nested, then I believe the
start/commit transactions should also be nested.
BTW, I believe originally the %modinfo definitions were not designed
to be nested, so I am not surprised that the XRL order is not as
expected.

> The problem above is that the XRL's between the rl_interfaces
> transaction are meant to be sandwiched between the interfaces
> transaction--when executing the create_interfaces the rtrmgr
> generates an error stating the TID is incorrect.
> 
> 
> If the rl_module creation is moved to another (subnode for
> instance), then the interface transaction proceeds correctly.

Are you saying that if the %modinfo declaration for the nested
rl_interfaces module is moved to one of the "ethernet" children
nodes, then the
start_transaction(rl_interfaces)/commit_transaction(rl_interfaces)
is nested within
start_transaction(interfaces)/commit_transaction(interfaces) even
without your modification?

ML> I don't recall if the transactions were nested in this case, but the xrls for interfaces/ethernet will correctly sequenced between the interfaces start/commit transaction statements in this case.

> The problem is when there are multiple transactions (which are
> caused by having more than one module transaction on the same
> node) on the same node. Note that loading order of the template
> file alters this behavior (if rl_interfaces.tp were changed to
> a_interfaces.tp--the transaction structure above would be
> different).

I am confused here. Are you saying that if the template file
ordering was changed, then the XRL ordering for the nested
transaction would be different? Is this true with or without your
modifications?
In any case, can you list the result XRL order.

ML> A module owns a node within the context of XrlAction::_module_name--which is assigned by the node that this XRL resides in. The assignment occurs when template_tree_node is passed into the constructor of the Action() base class. 

The class TemplateTreeNode only has a single slot for TemplateTreeNode::_module_name. I believe that the variable TemplateTreeNode::_module_name is assigned on start of the rtrmgr and the _module_name is assigned by the last module to be declared within the context of the node. Transactions use XrlAction::_module_name to determine the owner/scope of the transaction. So if the order of the loading of the template files is changed and the definition of modules are overloaded at the same node then the behavior of the transactions could change. There might have left out a couple details as this is from memory--but should be close...

Thanks,
Pavlin