Great Circle Associates Network-Automation
(December 2005)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: Notes from LISA Network Automation BoF
From: Brent Chapman <Brent @ GreatCircle . COM>
Date: Thu, 22 Dec 2005 19:07:28 -0800
To: David Magda <dmagda @ ee . ryerson . ca>,Network Automation List <network-automation @ greatcircle . com>
In-reply-to: <035BE0DB-CDC4-4668-99F9-FD6E57DD3473@ee.ryerson.ca>
References: <200512230034.jBN0YjV30525@dot.dauith.com><035BE0DB-CDC4-4668-99F9-FD6E57DD3473@ee.ryerson.ca>

At 9:22 PM -0500 12/22/05, David Magda wrote:
>On Dec 22, 2005, at 19:34, David Harnick-Shapiro wrote:
>
>>>	Indiana University NOC Tools
>>>		Luke Fowler paper
>>
>>There was also a reference made to Trey Harris' paper,
>>probably from the previous LISA, which discussed a different
>>way to look at configuration, with validation.
>
>Can anyone shed light on these two papers? Given Mr. Harris' 
>involvement in USENIX and SAGE his name appears all over the place, 
>so narrowing things down is a bit tricky.

Trey's talk was an invited talk at LISA 2004 in Atlanta; it was about 
the power of "Guarded Commands", which he implemented through a Perl 
module named "Commands::Guarded" 
(http://www.annocpan.org/~TREY/Commands-Guarded-0.01/Guarded.pm).

Here's a good discussion of the problem and solution from the module docs:
http://www.annocpan.org/~TREY/Commands-Guarded-0.01/Guarded.pm#an_example

Essentially, the idea is that lots of folks write configuration 
scripts with lots of steps in them that make two unwarranted 
assumptions:

1) The step needs to be done (i.e., it hasn't been done already)
2) The step succeeds (so you simply proceed to the next step without checking)

One consequence of this style of scripting is that, if such a script 
fails part way through, you can't simply fix the problem and rerun 
the script because you might inadvertently and incorrectly repeat 
work that's already been done.

Commands::Guarded makes it easy for you to write scripts as a series 
of steps, where each step includes a condition (a test to see whether 
the step has succeeded) and a set of commands that (if executed) 
should cause the condition to become true.  Each step composed of 
CONDITION and COMMANDS is then executed according to the following 
pseudo-code:

	unless (CONDITION) {
		COMMANDS;
		die unless (CONDITION);
	}

The Perl module also includes facilities for rollbacks, sanity 
checks, and so forth, but that's the idea in a nutshell.  It's a very 
powerful idea to apply in a configuration management context, whether 
of servers or network devices.


-Brent
-- 
Brent Chapman <brent@greatcircle.com> -- Great Circle Associates, Inc.
Specializing in network infrastructure for Silicon Valley since 1989
For info about us and our services, please see http://www.greatcircle.com/
Great Circle Waypoints Blog: http://www.greatcircle.com/blog


References:
Indexed By Date Previous: Re: Notes from LISA Network Automation BoF
From: Luke Fowler <luke@indiana.edu>
Next: NANOG in Feb in Dallas
From: Paxton <paxton@binsh.com>
Indexed By Thread Previous: Re: Notes from LISA Network Automation BoF
From: Luke Fowler <luke@indiana.edu>
Next: Re: Notes from LISA Network Automation BoF
From: David Williamson <dlw@tellme.com>

Google
 
Search Internet Search www.greatcircle.com