Re: lock

[Martin Bjorklund <mbj@tail-f.com>]

Hi again,

Since I didn't get any replies on this I'll try to rephrase.

It is recommended that locks are used when working on the candidate.
But the candidate is reverted to the running as soon as the lock is
released.  The only way to save the changes done after a lock is to
commit.  This means that the candidate can only be used by a single
client before committing to running.

From the rest of the text (e.g. section 9 and 8.3.1) I don't think
this is the intention?

Why isn't the special semantics of lock of the candidate (8.3.5.1 and
7.5) simply removed?

[Ok, I realize that you _can_ get the same effect by using a local URL
- clients always write with locks to a local file.  When it's time to
commit, you first copy-config from the local file to the candidate,
then issue a commit command, possibly w/ a timeout.]



/martin


Martin Bjorklund <mbj@tail-f.com> wrote:
> Hi,
> 
> In section 7.5 <lock>, the draft says:
> 
>       A lock MUST not be granted if any of the following conditions are
>       true:
> 
>       [...]
> 
>       *  the target configuration has already been modified and these
>          changes have not been committed or rolled back
> 
> I assume that this mean that the last condition applies only to the
> candidate configuration, since this is the only target configuration
> that can be committed through NETCONF. So the text could have been:
> 
>       *  the target configuration is 'candidate' and it has already
>          been modified and these changes have not been committed or
>          rolled  back.
> 
> Is this correct?
> 
> 
> What is the purpose of this condition?  Suppose user A is a good
> citizen and takes a lock and modifies the candidate, then releases the
> lock.  Then, before committing, A wants to do another change.  So A
> tries to grab the lock again - but this will fail since there are
> uncommitted changes.  So A has to do the changes w/o the lock or do
> discard-changes, take the lock, redo all original modifications, do
> the new modifications, and then commit.
> 
> Section 8.3.1 also says:
> 
>    The candidate configuration may be shared among multiple sessions.
>    [...] It is therefore prudent for a client to lock the candidate
>    configuration before modifying it.
> 
> 
> Is the intention that you have to commit after each modification?
> 
> 
> 
> /martin
> 
> --
> 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/>

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