On 10/06/2009 04:50 AM, Bruce Simpson wrote: > Ben Greear wrote: >> If there is no status and no startup method in a xorp target, the >> router-mgr uses a 2-second >> sleep for 'verification'. This slows down startup of Xorp quite a bit >> when you have lots >> of protocols running. >> >> This patch adds startup methods to many of the common targets. There >> are still more to >> go, however. > > Thanks for tracking this down; yes, I've noticed that process startup is > slower than it could be, but have only had free time / mindspace to look > at the XRL specifics. > > Could this be made a more general change? If the XIF method for startup > you are adding is not specific to a particular protocol, it might be an > idea to make it part of the common.xif -- which is where most of the > process control knobs are. > I'd rather not get too far into the machinery here, because I'm about to > take a badly needed break. I guess the firewall and ifmgr modules are a > special case, because they're separate service bundles located in the > FEA process.
It could probably be put in common code. I'm just learning this code myself...likely can get a cleaner patch later when I understand things better. > > On a more general note: > One of the things Pavlin raised in an old BugZilla ticket, is the fact > that the Router Manager is fairly complex because it implements > transactions on the config tree itself. > If this is pushed into the protocols themselves (they'd have to keep > their own config snapshot, and adopt a commit-rollback transaction model > in the XIF RPC interfaces), then the Router Manager gets a bit simpler > overall. I dislike that because then it would become virtually impossible to restart failed protocol processes. I think the rtr-mgr should hold all config state. As mentioned earlier, I think the commit/rollback thing has been somewhat over-thought as well. There are way too many ways to fail a commit...I think it should only fail if there are logical issues (and in that case, the rtr-mgr shouldn't even try to 'commit': it should not even accept the change in the first place.) If it tries to push something to a module and that module reports error, then we flag that piece of configuration as pending, or invalid, or similar and these flags would show up when the user did a 'show run' or similar. Then they know they need to fix it, perhaps by re-configuring, or perhaps by fixing broken hardware, or some other external thing. My various patches to not fail commits when we don't have to is my ongoing effort towards this type of behaviour.... Ben > > cheers, > BMS -- Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
