[rancid] Re: [PATCH] Use Git to store configs

Jeffrey C. Ollie jeff at ocjtech.us
Sat Mar 31 02:17:02 UTC 2007

On Fri, 2007-03-30 at 14:19 -0700, Austin Schutz wrote:
> On Fri, Mar 30, 2007 at 06:53:38AM -0500, Jeffrey C. Ollie wrote:
> > Here's a patch that I've been working on that allows you to store your
> > configs in a Git[1] repository.
> 	I like the change to case() where the syntax differs.

Yeah, switching to case will make it much easier to add other revision
control systems in the future.

> > Adding a third RCS system necessitated a little bit of code
> > reorganization, so I may have inadvertantly broken something (I haven't
> > tested CVS or Subversion repositories with the patch applied).  The
> > other big differences are:
> > 
> > 1) When using CVS and Subversion, RANCID is working on local checkouts
> > (located in $BASEDIR) of a repository that is located elsewhere on disk
> > ($CVSROOT).  Git works differently, so $BASEDIR is the complete
> > repository and $CVSROOT isn't really necessary.
> 	$BASEDIR is the dir into which all groups go. If you put a generic
> lockfile here you will make it so multiple groups can't be polled at one
> time. Typically a temp dir is used where the file includes the group name
> so there is no stepping on of toes, and stale lockfiles aren't left in
> unexpected places.

The locks shouldn't slow down polling, the lock is only held when making
commits to the Git repository which shouldn't happen during polling
(unless I'm misunderstanding something about the code).  I needed the
locks because I need to run a series of git commands atomically or
changes from other groups might become part of the wrong commit.

> > 2) Since there could be multiple processes acting simultaneously on the
> > same repository (with CVS and Subversion RANCID had a separate checkout
> > for each group) I guard all operations on the repository using flock(1).
> > flock(1) does not operate over NFS.
> > 
> 	IMO that's a problem: flock isn't available on all platforms, and
> dealing with nfs support could be annoying. I have a perl based lock
> script which uses fcntl (works w/ nfs) and should be reasonably cross
> platform, if that's useful (no other dependencies). Rancid's existing lockfile
> support is fairly dumb (simple). I get stale hangs sometimes after a reboot,
> myself- though it generally doesn't have to be that smart because it doesn't
> run that often.

Yeah, that too bad that flock isn't widely available, since it works
perfectly for what I needed.  Does your script work in a similar method?

> >  fi
> > @@ -138,6 +138,7 @@ then
> >      rm -f .cvsignore
> >      cat >.cvsignore <<EOF
> >  .cvsignore
> > +.gitignore
>   ^^^^^^^^^^^ this seems a little funky to me. Seems like there should be
> an if/then or switch/case for git here and in the surrounding code.

Yeah, the .cvsignore should probably be special-cased as well, and for
Subversion there probably shouldn't be a file at all.  I think I have
something in mind, I'll see if I can get around to coding it up.

> > @@ -265,21 +280,27 @@ then
> >      cd $DIR/configs
> >  
> >      # Add new routers to the CVS structure.
> > -    for router in `comm -13 $DIR/routers.up $DIR/routers.up.new`
> > +    for router in `comm -13 $DIR/routers.up $DIR/routers.up.new | cut -d: -f1`
> 	If there are other bugs you might want to submit them independent of
> the git changes.
> > +    case $RCSSYS in
> > +	cvs )
> > +	    cvs status $router | grep -i 'status: unknown' > /dev/null 2>&1
> > +	    if [ $? -eq 0 ]; then
> > +		touch $router
> > +		cvs add -ko $router
> > +		echo "$RCSSYS added missing router $router"
>                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 	This doesn't need to be repeated for each case statement.

I'll look into refactoring that.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.shrubbery.net/pipermail/rancid-discuss/attachments/20070330/c0b8ed47/attachment.bin 

More information about the Rancid-discuss mailing list