[rancid] multiple files

[heasley]

Mon, Mar 17, 2014 at 09:47:33PM +0200, 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.

just poll the device twice, eg: two groups or a cname.  i do this, using 3.0a,
to collect regular and xml versions of juniper configs; so the xml collection
is just a different device type.

> 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

XML is truly awful.

> 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
> 
> _______________________________________________
> Rancid-discuss mailing list
> Rancid-discuss at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo/rancid-discuss