On 03/17/2011 10:32 AM, Ray Soucy wrote: > I've been out of the loop on CT changes as we are still a 1.6 > environment in production. Now that CT is merged into official I have > a few questions on 1.8.3 vs 1.7 svn. > > In 1.7 we saw a lot of work to move to start using Boost. I see that > in 1.8.3 it's a build option called "enable_boost" that defaults to > False, what's the extent of Boost in 1.8.3? Is it supported, or are > we moving away from that change? Pros vs. Cons? Suspect that it was > done to cut down the footprint, but will it be actively maintained > going forward I guess is my real question.
Boost was never used much, and now by default it isn't used at all. I left it in because some folks liked it, but I'd be happy enough to remove it entirely. If you have a reason to use boost, please do let me know. I'm not going to add external dependencies and big frameworks just for the fun of it though...it has to solve a real problem or provide a measurable benefit worth the overhead. > Numbering-wise, I think we might call this release 1.8.0 since 1.8 > doesn't exists for XORP (realize it does for CT). Also the version > reported by xorp needs to be updated (it's still reporting 1.8-CT). Please let me know what exactly you downloaded and where it reported 1.8-CT: I thought I had that fixed last night. Since I already have 1.8.2 on the github site, I need to bump this to beyond that, so I think we can't re-use 1.8.0. For that matter, 1.7 was never officially released either. It should be smoother going forward, at least. > Also think that it would be nice to maintain the same format for > RELEASE_NOTES that was previously used by the XORP project. The CT > RELEASE_NOTES got a little out of control with the inclusion of the > Git log and style changes. Here is an example for 1.8.0 (which would > come right before 1.7): > > Release 1.8.0 (2011/03/17) > ============================ > ALL: > - XORP-CT branch merged into XORP. > - New release numbering (1.8.0 vs 1.8) to accomodate more frequent > updates. > - New build options allow for exclusion of XORP modules. Well, I think the shortlog could help someone who wanted the details, and when other folks send patches, they'll get their name in there, which is often the only payment rendered :) > ... > > Testing looks OK so far in VMs. > > Init scripts for XORP is still something thats a little flaky. I > checked and the xrl sockets are created with the correct permissions > now, which keeps xorpsh happy. > > I tried writing a new init script that sends SIGKILL to xorp_rtrmgr > and lets XORP shutdown gracefully, but ran into a bug with it deleting > interface configuration when it shuts down for any interface defined > in the config, even if "restore-original-config-on-shutdown: true" is > set. Please open a bug on that, and let me know if it's a regression or not. Probably won't attempt to fix this for 1.8.3, but hopefully next release. > The result on my test VM is that eth0 and lo no longer have IP addresses. > > Graceful shutdown does clean up xrl socket files correctly now too. > > The shutdown process is also very slow, meaning a long restart time. > I'm wondering if the work on async methods will help that in any > way... I haven't done much work to make shutdown fast, and in fact, the work I did to gracefully clean up xrls, etc, means shutdown is slower, often waiting on timers to expire and such. For fast restarts, a kill -9 and manual cleanup of the xrls might be the way to go. > > I was also unable to get rtrmgr to use syslog. Did that used to work? Please open a bug on it either way, with info on how you tried to configure it, etc. > I also wrote a quick companion CRON script that will check if rtrmgr > has crashed and attempt to restart XORP if that is the case. I > haven't run into XORP crashing while up and running personally, but > its a nice "self healing" kind of check, and doesn't cost much of > anything to do. Pardon the echo ugliness, I wanted to write the log > file in a format consistent with XORP. A wrapper script that starts xorp_mgr in non-background mode in a loop (and cleans xrls, logs, etc when rtrmgr dies) is how I handle that. Might be slightly quicker on the restart and less overhead when everything is running smooth... Thanks for the detailed testing! Ben -- 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
