I agree that testing is a great idea (in my former job I was a test engineer
for Lauerl Networks) but just random testing on contrived topologies
my provide a false sense of stability.
<taking a big hit on the crack pipe>
I'm not saying I have the answer, but stick with me for a second:
-the hardest part of testing is knowing what to test and how to test it
-the people who know what/how to test are typically not the ones who
have the equiptment or time to do testing
Given the above, automated testing on specific topologies written by
those who know what/how to test might allow those who have time/equiptment
to provide reliable information about the state of the code.
This means we would have to implement an automated test infrastructure,
design the topologoies, and then write the tests. Granted this is enough
work for an open source project in an of itself, but in a perfect world
this is how open source regression testing could work.
</exhale>
I'll start the long walk back to reality now ....
--
James R. Leu
On Tue, Aug 05, 2003 at 12:36:14AM +0100, Paul Jakma wrote:
> On Mon, 4 Aug 2003, Kevin C Miller wrote:
>
> > I've always thought this would be extremely beneficial for zebra.
>
> err.. you mean quagga :)
>
> It'd be /immensely/ beneficial. Eg, the recent NSSA ABR translation
> work i did was because i had access to a Cisco to verify behaviour
> (and obviously because i needed translation :) )
>
> > I have 3 2500s, a 2600, and a 4000 that could potentially be used
> > for this purpose, as well as some machines of various OSs.
> >
> > Ideally, a lab environment with OOB console access to all this
> > stuff would be great;
>
> yep.
>
> > the aforementioned testbed is in such an environment, though
> > currently external access would be a little tricky.
> >
> > I think that if there was a 1 page summary of this on the table, it would
> > identify the needs and get things setup.
>
> In an ideal world:
>
> - Several Unix, BSD, Linux hosts.
> (RH9, Debian woody (?), FreeBSD 5, FreeBSD 4.2, OpenBSD (?)).
> Possibly SunOS too.
>
> - equipped each with at least one ethernet port, one serial
> console
>
> - if possible equipped with at least one serial port for testing
> lower speed / PtP links + required null serial cables.
>
> - if possible sync serial cards for testing interoperability
>
> - As many other implementations of routing protocols as we can find
> ideally IOS 11.x, 12.x and IPv6 train IOS. JunOS would be nice too :)
>
> - One managed ethernet switch or hub capable of configurable
> segmentation of its ports (eg VLAN)
>
> - One remotely accessible management host (eg with a multiport serial
> board to manage the serial consoles). Preferably with a suitable
> environment for doing development.
>
> - An on-site contact person with whom to arrange reconfiguration if
> needs be, kicking of boxes if needs be.
>
> - Someone to coordinate access (possibly previous person)
>
> - BGP feed somehow (from an on-site route server?). Easiest way to
> get a BGP feed which is known to be representative of real-world
> conditions is to get a real feed.
>
> Purpose:
>
> Facilitate development of portable fixes/enhancements to Quagga, by
> way of having easy access to the main platform types supported by
> Quagga.
>
> Facilitate development of fixes/enhancements to protocols supported
> by quagga and, who knows, development of protocols not yet supported
> by Quagga by way of providing a homogenous environment for
> interoperability testing, at both the early development stage and
> more traditional interoperability verification stage.
>
> Would be very nice to have anything resembling the above, obviously.
>
> > -Kevin
>
> regards,
> --
> Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
> warning: do not ever send email to spam@dishone.st
> Fortune:
> Make it myself? But I'm a physical organic chemist!
>
> _______________________________________________
> Quagga-users mailing list
> Quagga-users@lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-users
