[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 13.6: Discard changes

At 04:21 PM 2/9/2004, Rob Enns wrote:
>On Mon, Feb 09, 2004 at 04:04:59PM -0800, Andy Bierman wrote:
>> At 03:16 PM 2/9/2004, Rob Enns wrote:
>> >> 13.16) <discard-changes>
>> >> 
>> >> 13.16.1) Clarifications [PROT]
>> >> 
>> >>   Says content 'automatic' is allowed for the <discard-changes>
>> >>   operation.  This is not actually documented.
>> >>    
>> >>   Closed: accepted, protocol document needs to be updated
>> >
>> >Here is the source of the confusion: there is a <discard-changes>
>> >operation which tells the device to discard any changes made to
>> >the candidate the configuration.
>> >
>> >There is _also_ a <discard-changes> argument specified as part of the
>> >lock operation which can indicate that the device should automatically
>> >discard any changes to the configuration when the lock is released 
>> >(either intentionally using <unlock/>, or implicitly, by session failure).
>> >
>> >The confusion can be fixed by renaming one of these elements. 
>> >We could rename the <discard-changes> argument
>> >to <rollback>, so that a lock request could look like:
>> >
>> ><lock>
>> >  <target><candidate/></target>
>> >  <rollback>automatic</rollback>
>> ></lock>
>> >
>> >and this element could be conditional on the (tbd) #rollback capability.
>> 
>> I really don't like this approach at all.
>> Rollback should not be coupled to the candidate config.
>> This is a separate feature that is not dependent on whether
>> the device supports writes to <candidate> or to <running>.
> 
>I am trying to propose _decoupling_ automatic rollback from the
>candidate config. :-) That's why I said to make it conditional
>on the rollback capability.
>
>> Why does the candidate config need its own extensions
>> to the <lock> command?  This seems like really bad design.
>> I think we should avoid special versions of the protocol
>> operations unless absolutely required.
>
>Perhaps we are in agreement, maybe I was not clear. What I'm suggesting
>is that we add the ability to specify that changes can be
>rolled back (from either the candidate or running) configuration.
>The reason to put it on the lock command is that lock/unlock
>are one nice way NETCONF has to bracket a set of changes.
>The other way is "all the changes in an <edit-config>", which
>is okay too, but not as flexible. If we do rollback in
>NETCONF, it should work both with a single <edit-config> 
>granularity, as well as the set of changes between a lock and unlock.

I need to review the #candidate details more closely.
The expected behavior isn't fully documented yet.
Let me see if I understand.  Here's text from sec. 7.5.5.1:

   On devices implementing the #candidate capability the default target
   of the <lock> and <unlock> operations is the candidate configuration
   datastore.

This is bad design and can't be properly described in the XSD.
Instead we should not have a default target for any command
(minOccurs=1, no default)

   Devices implementing the #candidate capability WILL NOT allow a
   configuration lock to be acquired when there are outstanding changes
   to the candidate configuration.  An error WILL be returned and the
   status of the lock will remain unchanged.

This seems backwards and creates a race condition.  
With no lock held, session A starts executing <edit-config>
operations on the candidate config.  Session B then
wants to obtain a lock and edit the candidate config,
but the <lock> request fails because session A made changes.
(The application for session B has to have special code to 
deal with locked failed because it's already held or lock failed 
because the candidate config has uncommitted changes in it.)

So session B needs to complete 2 successive RPCs
(a <discard-changes> followed by <lock>) without session A
executing an <edit-config> (after the <discard-changes>
but before the <lock>).  

It seems simpler to have <lock> succeed, and then session B
can choose to execute <discard-changes> before editing
the candidate config.  Subsequent <edit-config> or 
<discard-changes> operations executed by session A would fail.

   When a client fails with outstanding changes to the candidate
   configuration, recovery can be difficult.  To facilitate easy
   recovery, the #candidate capability adds a <discard-changes> element
   to the <lock> operation.  If this element contains the value
   "automatic", any outstanding changes are discarded when the lock is
   released, whether explicitly with the <unlock> operation or
   implicitly from session failure.

This is confusing.  The <discard-changes> is added to
the <lock> operation, but doesn't discard previous
changes, it discards any future changes by the lock owner
if that session terminates without issuing an <unlock>.
It seems to me that terminating without a <commit> is either
intentional or a rare event, not worth optimizing.

I think we should get rid of this extra parameter on <lock>.  
If the session terminates without releasing the lock, then any
uncommitted changes get discarded.  


>thanks,
> Rob

Andy



>> 
>> >thanks,
>> > Rob
>> 
>> Andy
>> 
>> 
>> >--
>> >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/>