[Xorp-hackers] AW: [Xorp-users] Does xorp latest CVS have some problem with the export command?

[Pavlin Radoslavov]

> I have seen some smaller and bigger rewrites in the way xorp will or would
> be configured, is it possible for the next release to add a way rtrmgr do 
> Not die when the configuration is "wrong" and to show this to the user only
> for the startup config?

Accidentally, this morning bugzilla entry #180 was resolved:
http://www.xorp.org/bugzilla/show_bug.cgi?id=180

It addressed the case when the rtrmgr would exit if you try to
change the configuration via xorpsh, and there was a missing
executable file for one of the new modules.
Probably it doesn't solve all bad "rtrmgr exit" scenarios when
changing the configuration, but is a step in that direction.
If you come across other cases when the rtrmgr exits during
reconfiguration please bring it on.

Note that exiting during startup if the configuration is bad is
an intentional behavior.

> May be add a functionality to rewrite old config into new one. And to
> provide help in the configure mode so the user would notify, that this way
> is obsolete, maybe for the next releases until Version 2.0?

We have already support for notifying the user if some configuration
statement is obsoleted: the "%deprecated" keyword in the
configuration template files. E.g., add "enabled: true"
config statement to an interface and try to start with or load that config
file. The rtrmgr will refuse and will print a predefined error
message.
Unfortunately this mechanism has its limitations. E.g., it can tell
you if a node in the configuration tree has been deprecated, but it
cannot tell you if the syntax of a node has been changed (as it
seems to be the case with the old/new policy for RIP).

We don't have yet a functionality to rewrite old configs into new
ones, because we are still in the process of tweaking various
things, and such tool will quickly become obsolete (or an additional
burden to maintain and keep it up to date).

Pavlin