Re: Issue 13.6: Discard changes

[Andy Bierman <abierman@cisco.com>]

At 10:14 AM 2/11/2004, Phil Shafer wrote:
>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.

I think we are in agreement on behavior, but not
on the documentation.

You're right about not wanting to hose the CLI user.
We don't want to hose any "write session" to a
configuration database.  Any sub-system, such
as the CLI, must acquire and release the lock 
(implicitly or explicitly).  This has to be the
case in the implementation or the CLI wouldn't
be able to issue an error message instead of
executing a config command.

So the documentation should reflect these implementation
requirements.  The candidate config is not a special
case.  The database target is not important here.
We don't need to say how other protocols besides
NETCONF acquire and release the lock, just that they
need to do it.

IMO, the following text should be removed from sec. 7.5.5.1:

   Devices implementing the #candidate capability WILL NOT allow a
   configuration lock to be acquired when there are outstanding changes
   to the candidate configuration.  An error WILL be returned and the
   status of the lock will remain unchanged.

We don't need this text.  The lock request fails because
the lock is already held in this case.  This text in
sec. 5.5 covers this case:

         An attempt to lock the configuration MUST fail if an existing
         session currently holds the lock.

This should be clarified to indicate that it must also fail
if a non-NETCONF sub-system holds the lock.

         When the lock is acquired, the server MUST prevent any changes
         to the locked resource other than those requested by this
         session.  SNMP and CLI requests to modify the resource MUST
         fail with an appropriate error.

This paragraph should say, "For example, SNMP and CLI ..."


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

Andy


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