[AusNOG] RANCID replacements [HIJACK]

[Andrew Fort]

On Fri, Oct 7, 2011 at 10:35 PM, Paul Gear <ausnog at libertysys.com.au> wrote:
> 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 :-) )?

Harder if you hate python ;), but not very difficult.

The device abstraction has a specific API, most methods of which do
not need to be implemented for most clients to work.  For example, to
work with the Mr. CLI client, one needs to only implement connect(),
disconnect() and cmd().

Knowing that the device interactions fall into expect over ssh/telnet
or command-send/command-response style (think sshv2 "exec" sessions),
I've abstracted those away into transport modules.  Device modules use
those transport modules (which have a variety of options for dealing
with all sorts of brokenness I've come across).

Also, since Notch is object oriented, you can say "well this thing is
kinda like IOS but behaves a bit differently when I need to confirm
the prompt", and override specific methods in your subclass of the IOS
device.

Those two things alone mean there's high code reuse.

The documentation could certainly be better, or more(r). While I've
had a few people post contributions on private branches, it's only
been me committing to the main branch, so I hadn't written a lot.

>
> 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".
>

One thing that interests me about the RANCID "mess" is that every
network shop I've worked at has had at least one (often more) hacked
RANCID device type that will never see their way back to shrubbery.

> 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 couldn't agree more :).

>
> 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. ;-) )
>

Heh. I've used rcs, cvs, svn, p4, monotone, hg and git, and actively
have to use three of those (hg, p4, git) so I feel that pain:). A lot
of IDEs have VCS abstractions, for what it's worth.

Point taken re documentation.  I'd like to write a guide to building a
device module and some better system documentation in general, since
being an RPC-over-HTTP distributed system that happens to be able to
do things like RANCID does is admittedly a little bit of a leap.
Since I am doing this entirely in my spare time it's tricky to make
progress sometimes, but if you have a look around in the code and have
any questions, please shoot me email.

You may wish to have a look here:
http://code.google.com/p/notch/source/browse/#hg%2Fnotch%2Fagent%2Fdevices

device.py is the abstract device class, defining the device API.  in
the parent directory, device_factory.py maps the configuration type to
the specific implementation module (a router.db device type or some
other string I made up where there was no existing rancid device type)

> Regards,
> Paul
>

-a


> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>