Re: Issue 13.6: Discard changes

[Phil Shafer <phil@juniper.net>]

Juergen Schoenwaelder writes:
>Human users type into a CLI not into memory - so why can the CLI not
>establish a suitable lock when the user is making configuration
>changes? This can be implemented either by a special lock CLI command
>which the user has to learn and use, or it can be bundled with some
>"enable" mechanism, or perhaps even be totally implicit and delayed
>until the first real change is being made. But at the end, I think the
>CLI should lock somehow.

This is what we've done in junoscript:

   JUNOS supports multiuser access to the configuration database.
   Configuration data can be viewed and modified by multiple clients
   (human or script) simultaneously.  To avoid disastrous interactions
   between clients, JUNOScript supports an exclusive lock on the
   configuration database.  This lock is granted if two simple
   conditions hold:

   o  No uncommitted changes exist, and

   o  No other entity currently holds an exclusive lock

   If the lock fails, a client script may retry at a later time.

   The database lock does not prevent other users from entering
   configuration mode or retrieving configuration, but blocks any
   attempt to modify the candidate database or to issue a commit
   operation.

It may be a fine point, but I don't see this as an implicit lock, just
circumstances that prevent a lock from being granted.  Either way,
it's required to protect the user from scripts.

Thanks,
 Phil

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>