|
Hi,
I think there is a real problem that exists, and Balaz's
reasoning effectively says "let's just ignore the conflict with access control;
then we can make believe the problem does not exist." This does not make the
problem go away.
The problem is that the scope of the lock and the scope of
the commit are different.
I believe that for partial lock on candidiate to work, you
need a corresponding partial commit.
This could be handled using an explicit command for partial
commit.
It could be handled by allowing multiple candidiates, each
containing a partial config that is specified as a parameter to the partial lock
(or to a partial-copy-config), with what is effectively a global lock of the
partial config and a global commit of that partial config.
The lock and the commit need to match scope. If they do not
match, you will have problems.
If the WG chooses to not have a partial commit that
corresponds to the partial lock, or multiple candidiate sandboxes that can allow
an operator to independently lock, edit, and commit a partial config,
then I think the partial lock for candidate should be removed.
That is not my preferred solution, because I believe
operators will need to lock and modify and commit partial configs, but removing
the partial lock from candidiate is probably the easiest for
now.
dbh
WG particpants,
Unfortunately, not too many people have given a clear
statement of their
opinion on the question if they could
accept Balazs' reasoning w.r.t. the
partial lock issues (see below).
But, based on the comments received, We (WG chairs)
have asked
Balazs to do a new rev that explains as much as possible what can
and cannot be done and what impacts it has?
Balazs has now done so and
revision draft-ietf-netconf-partial-lock-08.txt
is now available. Revision 7 was already handed to our AD
for review
and IETF Last Call, and we believe that this new revision
addresses
(or at least explains) the last issues that came up before
our AD could
do an IETF LC for rev 07.
We have asked Dan (our AD) to pick up revision 08 for IETF
Last Call.
I assume all WG members are now OK with this revision. We
have
(in the WG chairs views) consensus (at least rough)
consensus.
If anyone still has concerns, you can always post them to
our NETCONF
mailing list and.or raise them during IETF Last
Call.
Thanks you all.
Bert and Mehmet
----- Original Message -----
Sent: Tuesday, May 19, 2009 8:51 PM
Subject: Re: [Netconf] Partial-lock
issues
Thanks Balazs for summarizing.
I believe I (as a technical contributer) can accept your
reasoning.
Speaking as document shepherd and WG co-chair I would like
to
urge all WG members to state their opinion (or comments) as
well.
Bert
----- Original Message -----
Sent: Tuesday, May 19, 2009 12:01
PM
Subject: [Netconf] Partial-lock
issues
Hello,
Some people brought it up that partial-locking
without partial commit is not a good solution as
it can lead to
dead-locks. For one last time I try to list the reasons why we included
candidate.
Please state if you can accept the reasoning below or
whether you think we should allow
partial-locking ONLY for the running
configuration?
1) As Washam pointed out just by having access control
and without using any locks we face a
dead-lock problems:
- A only has
access to /foo, and edits it in candidate
- B only has access to /bar,
and edits it in candidate
- A terminates it's session
- Now B can not
issue <discard-changes> because it can not modify /foo in the
candidate
- B can not issue <commit> because it can not modify /foo
in the running
If A and/or B uses partial-locking that will NOT make this
situation WORSE, as the lock is
automatically released at the end of the
session. The real problem is caused by access control.
2) When
partial-locking is used correctly, there is no danger of dead-lock, and
locking does
help to protect the individual operator's activities. (In
the next sequence we presume access
control will not block any of the
actions.)
- Operator A locks everything it needs both in candidate
and running in one operation e.g. /foo
- A edits the locked part in the
candidate
- A issues commit, if this fails due to lock conflicts, it
simply releases the lock, and let's
any concurrent operator (e.g. B) work
on candidate; B will later commit changes done by A as
well. Lock
conflicts can include operator B locking /bar in the running
configuration
- Operator B works the same way on another area e.g.
/bar
- The operator that finishes editing last will successfully commit
all changes to running (by
this time there are no other locks)
3)
Later we might introduce partial commit, in which case partial-locking would
be very much
needed/useful
4) Partial-locking does no
evil
5) It is nice to have the feature available on all three
datastores
So we propose to keep partial-locking on candidate, but as
this is only secondary use-case if
the workgroup decides it can be
removed.
This question has already been raised a number of times, so
we would like to establish the
workgroup
consensus and follow it.
PLEASE INDICATE WHETHER PARTIAL-LOCKING ON CANDIDATE SHOULD STAY
OR
SHOULD BE REMOVED
!!!!
Balazs
|
