Re: lock

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

Phil Shafer <phil@juniper.net> wrote:
> Martin Bjorklund writes:
> >> 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.
> 
> We're trying to make something that will integrate easily
> with existing implementations and existing usage scenarios.
> So there's no "making [ancient users] take a lock".  Users
> will enter and perform their ritual tasks in the Temple of
> the CLI without changing their actions.  Forcing a new world
> order on them is a non-starter.

Agreed.  But the CLI engine etc could do that for the user.  The CLI
engine must be aware of NETCONF locks anyway, as defined in the specs
(7.5).

> >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.
> 
> The suggestion is that locks always be used, but we make allowances
> for folks that avoid locking (for unknown reasons).  Most of this
> is fallout from earlier drafts when locking was (for unknown
> reasons) an optional capability.

Ok.

> >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.
> 
> Yup, those are your choices.  You can use it as a transaction mechanism
> for a single client, given protection and predictability to your world, or
> you can use it as a shared workspace, with the assumption that all those
> sharing the resource are sane and well-behaved.

They don't have to be evil, you can get strange results if no locks are
used just by bad timing.

> >"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.
> 
> We don't want to force anyone to do a full get-config.  If you
> just want to make a couple of minor changes, you don't need to
> traffic the entire config.


Thanks for the clarifications!  Maybe some of these clarifications you
just sent could go into the specs to make the intentions more clear
for new readers?


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