[Xorp-hackers] Release 1.8.3 is almost done, please test

[Ben Greear]

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 <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com