Re: lock

[Phil Shafer <phil@juniper.net>]

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.

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

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

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