[rancid] multiple files

[Alan McKinnon]

On 17/03/2014 20:40, Siegel, Richard wrote:
> Good day!  I am new to rancid git, and had a question regarding
> extensibility of functionality for using rancid against directory of xml
> files on a server. 
> 
>  
> 
> Could a single device class (a vendor) write out multiple .new files? 
> Has anyone done anything like this, or can refer me to it?  I get that I
> specify a device, and it creates a device.new, and tell rancid about
> this new class of device.  But could I create a device-myfile1.new and a
> device-myfile2.new and will something like this work or is this not what
> will be expected…
> 
>  
> 
> I hope this is clear.


rancid is software so anything is possible but I fear you will need to
do a large amount of refactoring first before your idea will work. The
files you mention are opened for reading in the script "rancid" on line
2069; the other parser scripts will have equivalent code.

The reason I suspect you will need to heavily refactor things is the
process the system follows:

1. rancid-run is executed and launches rancid_control for each
LIST_OF_GROUPS
2. control_rancid reads router.db and launches rancid-fe for each device
3. rancid-fe launches the specific parser for that device type
4. The parser (eg. the rancid script) logs into the device, runs the
list of commands for that type, grabs the output, stores it, *****, and
processes it line by line. Then stores the new latest copy if changed in
a repo.

What you desire to do is to inject new data at point *** in #4 above.
The code is simply not written to take account of this - it's at line
2069 in the script "rancid" - and all the prior setup actions that
usually happen will not happen in your case.

Hence why I say the code must be refactored. It might be an interesting
exercise to find out exactly what it will take to do this (I can think
of several edge cases on my network where I could use such a feature)
but to the best of my knowledge no-one has done it yet.

The use of XML is also going to cause a world of pain, CVS does not cope
nicely with it. Devs know that XML is really like a gigantic associative
array where order of tags doesn't matter and newlines between tags are
mostly optional. Especially with in-house code, the on-disk format is
liable to change without warning and this drives CVS nuts. It will then
drive you nuts.

XML is truly an awful storage format, it really only does well in
transport. You might have to pass your data files through a pretty
printer first to ensure a consistent format before you can rely on
rancid's diffs.


-- 
Alan McKinnon
alan.mckinnon at gmail.com