Re: unified transaction model proposal

[Andy Bierman <abierman@cisco.com>]

At 07:45 AM 4/27/2004, Juergen Schoenwaelder wrote:
>On Fri, Apr 23, 2004 at 01:00:53AM -0700, Andy Bierman wrote:
>> Here's something new to throw darts at... a proposal for
>> a unified transaction model (for target == <candidate> or <running>)
>> -------------------------------------------------------------------
>> 
>>  <lock>
>>  <edit-config> +   // 1 or more
>>  <commit> OR <discard-changes> 
>>  <unlock>
>> 
>> where:
>> 
>>    commit =
>>      - if #candidate then 
>>          attempt commit of <candidate> to <running>  
>>      - release any 'rollback' resources the agent was using
>>        for this transaction.  
>>      - if #distinct-startup then
>>          copy(running, startup)  
>> 
>>    discard-changes =
>>      - if #candidate then 
>>          target is <candidate>
>>        else 
>>          target is <running>
>>      - remove all changes made to the target by this transaction
>>        since the lock operation completed
>> 
>> --------------------------------------------------------------------------
>> 
>> IMO, this would greatly simplify the transaction model
>> and make application development easier.  It also makes
>> network-wide config updates easier on the application.
>> 
>> The changes to the protocol operations are:
>> 
>>   1) <commit> is part of base protocol
>>      - confirmed-commit still a #candidate extension
>>        and available if #confirmed-commit present
>>   2) <discard-changes> is part of the base protocol
>>      - this is essentially a rollback of multiple
>>        edit-config operations, which is needed in
>>        addition to rollback-on-error 
>
>Perhaps this should then be named "rollback" (or "commit" be changed
>to "apply-changes" ;-).

I kind of like <commit> and <discard-changes>


>>   3) for implementations that have target==<running>,
>>      a rollback capability is mandatory.  This is a
>>      big requirement and raises the bar for NETCONF,
>>      but this will make the protocol easier to use
>>      for all application developers.  
>
>Just for clarification: I assume correctly that commit/rollback
>only applies to changes created via <edit-config> and not to any
>other changes (e.g. <copy-config> or <delete-config) that may be
>made since the lock was established.

Good question.  I don't think this is the case though.
We have global targets (<candidate> and <running>).
If locking is not used, then the agent cannot
prevent additional sources from making changes.
Also, a <discard-changes> applies to the whole database,
not just the changes from the <edit-config> operations
from the current session.

We have explicit <lock> and <unlock>.  It's up to the
application to use it correctly.  Since this can't
be guaranteed, my proposal above won't work.  What
if the application didn't use <lock> or did this:

  <lock>

  <edit-config> +   // 1 or more
  <commit> OR <discard-changes> 

  <edit-config> +   // 1 or more
  <commit> OR <discard-changes> 

  <unlock>

The <lock> can't be used as the start point.
So instead we have:

  <lock>

  <start-edit>    // no parameters
  <edit-config> +   // 1 or more
  <commit> OR <discard-changes> 

  <start-edit>    // error if previous trans. still open
  <edit-config> +   // 1 or more
  <commit> OR <discard-changes> 

  <unlock>


>/js

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