Re: Issue 13.6: Discard changes

[Phil Shafer <phil@juniper.net>]

Andy Bierman writes:
>On one hand, you say never stop the human operator
>from using the CLI, but if the lock is already obtained,
>it's okay to print an error message telling the human
>that the configuration can't be modified right now.

I don't say "never stop", I say "never hose".  If
there are uncommitted changes, a lock cannot be
safely granted, since it would require either
discarding the user's changes or commiting them
along with the lockers new changes.  Since neither
is acceptable, the easy answer is to fail the
lock request.

>My point is that the introduction of configuration
>locking has system-wide impact.  The CLI code will
>have to be aware of locking.

The code will have to be aware of it, but the user
should not be.

>The NETCONF I-D doesn't say that the lock is denied
>only if the candidate config contains uncommitted
>changes via CLI.  

Right, it says only says that the lock will be denied
if uncommitted changes exist from any source, since
it is unsafe to grant a lock at that point.

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/>