[AusNOG] RANCID replacements [HIJACK]

[Paul Gear]

On 08/10/11 03:23, Andrew Fort wrote:
> ...
> PUNC is a RANCID replacement.
>
> ...
>> How does it compare to RANCID etc in compatability with multiple
>> devices and backing up configs etc, or is it used differently?
>
> It uses mercurial (hg) for config storage. This also means you can
> run hgweb easily for the web differ, and it is compatible into other
> things like fisheye, crucible, etc.
>
> It doesn't support as many device types as RANCID.
> ...
> The devices supported are listed below, in the code. The VENDOR_MAP
> there takes a RANCID router.db device type (where there was a device
> type matching), have a look at the modules pointed to for a little
> more info on the device specifics.
>
> http://code.google.com/p/notch/source/browse/notch/agent/device_factory.py
> ...
> So with a large network, there's reasons to consider alternatives.
> But at the small size, the community and history behind RANCID make it
> preferable for many shops (unless they really hate Tcl and Perl ;-).

Hi Andrew,

How hard is it to add new device types to notch (especially for avowed
Python-haters :-) )?

I've long wanted an alternative to RANCID that i could recommend,
especially since i've had occasion to add a couple of new device types
recently, and also because of a couple of long-standing tricky bugs that
are not high enough priority to spend a lot of time on, but annoying
enough that every time i see them in a report, i promise myself that
i'll fix them "soon".

As soon as you try to add device types without reinventing the wheel,
RANCID starts to show its age.  There's so much complexity and so much
knowledge of different devices trapped in those kludgy bits of expect
code that one would have to be crazy to try to fix it with a
comprehensive abstraction layer now.  The point in time at which RANCID
has needed an equivalent to notch was about the time they added the 3rd
device type.

I would switch in an instant if the process for adding device types was
straightforward and well documented.  (Despite having to cope with a new
language and a new revision control system - it seems i have to do both
every time i start using a new tool nowadays.  Insert witty quip here
about the great need for a VCS abstraction layer that allows everyone to
keep their existing skillset. ;-) )

Regards,
Paul