Re: lock

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

Phil Shafer <phil@juniper.net> wrote:
> >This means that the candidate can only be used by a single
> >client before committing to running.
> 
> This is the intent.

Ok.

> >Martin Bjorklund <mbj@tail-f.com> wrote:
> >> 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.

> >> What is the purpose of this condition?
> 
> To prevent applications from (a) stealing the lock while a human
> user is in the process of making changes, and (b) preventing the
> script from committing changes which it did not make.

I thought that (a) would be avoided by making the CLI/WebUI/whatever
take a lock as well.

But a script is allowed to make changes and even comitting w/o taking
a lock.  Since the draft talks about the candidate as possibly being
"shared among multiple sessions" and also the text in section 9; I
assume that the intention is that sometimes NETCONF locks will be used
on the candidate and sometimes not?  So a script can decide by itself
if it wants to commit changes it didn't make or not.

I'm just a bit surprised - I thought that the candidate was a
persistent, shared, "scratchpad" configuration which could be made
consistent using locks.  As it is now, it behaves differently if locks
are used or not - if locks are not used, it's a persistent shared
scratchpad configuration which may or may not be consistent, but if
locks are used it's a way of doing a transaction for a single client.

Wouldn't it be more clean to separate these two functions?


> >> 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.
> 
> "A" would have no idea what changes are outstanding when it re-aquired
> the lock.  Its changes could have been discarded, committed, or added
> to.  If you could release the lock with outstanding changes or aquire a
> lock with outstanding changes the application would have no idea of the
> state of the configuration.

"A" would have to do a get-config first of course, just as it would
have to do if the changes were committed - after a commit, anyone
could have made the changes you describe above.



thanks

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