Re: Interactive vs Batch modes

[Joe Provo <crimson@gweep.net>]

On Tue, Jun 26, 2001 at 12:22:28AM -0700, Bill Woodcock wrote:
[snip]
> I think that there shouldn't be a modal distinction between batch and
> interactive configuration, if it can be avoided...  Again, there seems to
> be a lot of consensus around the idea that syntax and replies and so forth
> should be identical, irrespective of the mode of communication.  
> 
> There are, as you say, a bunch of different ways of getting configs into a
> device, and as you say, the error handling and reporting may necessarily
> be different.
> 
> 1) Issue commands interactively, receive interleaved error reports.  Error
> handling consists of ignoring invalid or unparseable commands.  Successful
> commands take effect interactively.  This is the way many vendors do it
> right now, and it has the advantage of allowing for mid-course correction
> if someone is working live, but the disadvantage of allowing situations
> where a config which would be valid when wholly entered exists in a
> temporarily uncommunicative state at some point as it's being entered:
> 
>     > telnet 10.10.10.10
>     > show configuration
>     interface Ethernet 0
>      ip address 10.10.10.10/24
>     > configure
>     config> interface Ethernet 0
>     config-if>  access-list 1 in
>     config-if> access-list 1 permit any any eq SMTP
>     -lost connection- 
> 
> ...despite you intention of typing "access-list 1 permit any any eq
> telnet" right on the next line.  This tends to argue in favor of having
> three copies of the configuration, rather than Cisco's two: nvram
> (persistent, what will be used at next boot), running, and a working copy
> which can be parsed and sanity-checked, but hasn't yet overwritten the
> running copy.
> 
> 2) Drop in a whole configuration at once.  This might be via HTTPS upload,
> or TFTP, or pasting into a terminal emulator across a serial line, or
> xmodem across a serial line.  If we have the distinction between working
> and running copies, we don't need a different mode to handle batch than
> interactive, really.  I think I'd like to be able to have config errors
> syslogged, in any event.  Basically you just need to be able to see the
> error reports directly associated with the lines which caused them.
> Perhaps a mandatory sanity-check of the working copy before it can be used
> to overwrite the running copy, and report errors then, whether or not they
> were previously reported?
 
Two observations:  
- three configuration images are a good thing and well-received by
  operators (cf juniper), but if we recommend a 'workspace' approach, we 
  should recommend the workspace be exclusive such that parallel accesses 
  do not collide on sanity-check or commitment to running or nvram images.
- (devils advocate) if we do not recommend a workspace approach (or are
  neutral on the topic) I'd return to the suggestion of at least 3
  verbosity settings on the communication protocol, and 'silent' would 
  give one the equivalent of a non-intewractive/batched mode.

-- 
 crimson@sidehack.gweep.net * jprovo@gnu.ai.mit.edu * jzp@rsuc.gweep.net
             RSUC / GweepNet / Spunk / FnB / Usenix / SAGE