YumaWorks

It is possible for the client to send several edits within a single <edit-config> request. Sometimes it is useful to make sure certain data structures are validated and processed before other data structures.

The "sil-priority" extension can be used to control the order of the edits and how they are processed.

For more information on how to use and set the "sil-priority" extension follow instructions How do I use sil-priority.

In a case where you set "sil-priority" for multiple specific objects and want the order to be reversed during the DELETE operations there is a netconfd-pro configuration parameter "sil-prio-reverse-for-deletes".

If set to "true" the "sil-prio-reverse-for-deletes" parameter for netconfd-pro dictates that the SIL priority for DELETE operations will be reversed. This parameter can be used to delete leafref nodes with referenced by node in reverse order.
If 'false' then the SIL priority will not be reversed. The default is "false".

When the parameter is set to "true" the server will invoke callbacks for the specific objects with "sil-prority" configured in reverse order.

The "sil-prio-reverse-for-deletes" parameter has following facts that should be noted:

• It will NOT change the "sil-priority" of the specific objects, it will instead reverse the "sil-priority" and the server will invoke the callbacks in reverse order
• This parameter will reverse "sil-priority" only if the edit operation is DELETE or REMOVE
• The server will not reverse the "sil-priority" for EDIT2 MERGE mode with mixed edits (if there is delete and other operations). Since the real operation is in the children objects and the server invokes a single callback for all the children edits at once.

Please note that the EDIT2 MERGE edits will not make any effect on the invocation order if the callbacks have mixed operations on children (if there are delete on one child and other edit operation on second child), they will not be reversed anyhow.

The EDIT2 MERGE mode combines multiple edits in one callback and the server invoke just one callback for all the edits. Hence, the server has no any control of when it should reverse the priority for this callback in case of mixed children operations.

The priority in this case will remain the same and the server will warn a user with following warning:

SIL priority for object 'uint16-leaf' set to 100.100
Warning: Cannot reverse SIL priority for EDIT2 child 'test:uint16-leaf'

However, in case the EDIT2 MERGE mode has only delete or remove operations on children the priority for this callback will be reversed.

It is recommended to avoid the EDIT2 MERGE mode with mixed operations if you want to reverse the priority of the edits.

Also, the server will reverse the edits priorities in case the EDIT2 children edit is the edit to delete or remove the default node. And if there is no any other children edits with not equal to remove or delete, or merge edit operation in case of default node removal.

As specified in the How do I handle different YANG object types with EDIT2 callbacks and what values should I expect? You can find more information on the different EDIT2 MERGE mode children operations and how they are set.

Example: Assume we have the following YANG module

module prio-test {
   ...
    container A {
      ywx:sil-priority 100;

      leaf someleaf {
        type uint16;
      }

      leaf nextleaf {
        type uint16;
      }
      ....
    }

    list B {
      ywx:sil-priority 200;

      key 'ref-key';
      leaf ref-key {
         type leafref {
           path "/A/someleaf";
         }
      }
      ....
   }
{

When you create /A and /B the server will apply regular priorities that are specified in the YANG module and the edits order would look as follows, from the server's logging:

***** start commit phase on running for session 1, transaction 1 ***** 
Start full commit of transaction 1: 2 edits on running config 
edit-transaction 1: on session 1 by --@::1 
  message-id: -- 
  trace-id: -- 
  datastore: running 
  operation: create 
  target: /A
  comment: none 

edit-transaction 2: on session 1 by --@::1 
  message-id: -- 
  trace-id: -- 
  datastore: running 
  operation: create 
  target: /B
  comment: none 

Now, if you want to reverse the priority during the DELETE operations in the next transaction. For example, during the create operation you need one specific order that is specified in the YANG module, but

during the delete operation you need to change the ordering and delete "B" first. Then you should set the "sil-prio-reverse-for-deletes" to "true" and the server will reverse the edits for you.

Now, when you delete "A" and "B" nodes the server will apply reversed priorities and the edits order would look as follows, from the server's logging:

***** start commit phase on running for session 1, transaction 1 ***** 
Start full commit of transaction 1: 2 edits on running config 
edit-transaction 1: on session 1 by --@::1 
  message-id: -- 
  trace-id: -- 
  datastore: running 
  operation: delete 
  target: /B
  comment: none 

edit-transaction 2: on session 1 by --@::1 
  message-id: -- 
  trace-id: -- 
  datastore: running 
  operation: delete 
  target: /A
  comment: none 

In case of EDIT2 MERGE mode make sure that the children operations are not mixing delete and create in the same edit. For example if you want to delete /B and two leafs in the /A "someleaf" and "nextleaf" the server will reverse edits priorities in this case since the EDIT2 object has children edit with only delete operations. But if you will try to create the leaf and at the same time delete some other leaf in the same EDIT2 parent node the server will not reverse edits priorities. So in case you only delete EDIT2 children of /A and delete /B, the server will apply reversed priorities and the edits order would look as follows, from the server's logging:

***** start commit phase on running for session 1, transaction 1 ***** 
Start full commit of transaction 1: 3 edits on running config 
edit-transaction 1: on session 1 by --@::1 
  message-id: -- 
  trace-id: -- 
  datastore: running 
  operation: delete 
  target: /B
  comment: none 

edit-transaction 2: on session 1 by --@::1 
  message-id: -- 
  trace-id: -- 
  datastore: running 
  operation: delete 
  target: /A/someleaf
  comment: none 

edit-transaction 3: on session 1 by --@::1 
  message-id: -- 
  trace-id: -- 
  datastore: running 
  operation: delete 
  target: /A/nextleaf
  comment: none 

Note, that in case of EDIT2 MERGE mode the server will not reverse the priority if the children operations are mixed deletes and creates. That's, if you delete /A/someleaf and, for example, create /A/nextleaf in the same edit then the server will start the EDIT2 MERGE mode and the callback operation will be invoked for /A container and the actual delete and create operations will be set in the child records.

Hence when you apply described operation, the server will apply regular priorities that are specified in the YANG module and the edits order would look as follows, from the server's logging:

***** start commit phase on running for session 1, transaction 1 ***** 
Start full commit of transaction 1: 3 edits on running config 
edit-transaction 1: on session 1 by --@::1 
  message-id: -- 
  trace-id: -- 
  datastore: running 
  operation: delete 
  target: /A/someleaf
  comment: none 

edit-transaction 2: on session 1 by --@::1 
  message-id: -- 
  trace-id: -- 
  datastore: running 
  operation: create 
  target: /A/nextleaf
  comment: none 

edit-transaction 3: on session 1 by --@::1 
  message-id: -- 
  trace-id: -- 
  datastore: running 
  operation: delete 
  target: /B
  comment: none 

In the scenarios where the data model utilizes the "sil-priority" extension with --sil-delete-children-first and --sil-prio-reverse-for-deletes options the server may change the order of the callbacks based on the priority and at the same time it may reverse the priority.

For example, assume the following simplified but functional data model:

  container interfaces {
    ywx:sil-priority 200;

    list interface {
      ncx:sil-delete-children-first;

      container vrrp {
        ...
      }

      container vrrp-ipv4 {
        ywx:sil-priority 245;

        list vrrp-instance {
          ...
        }
      }

      container vrf {
        ywx:sil-priority 255;
        ...
      }
    }
    ...
  }

1) Now, assume we run CREATE on "/interfaces" with a list entry and all the children.

This operation will produce the following SIL callback invocation order:

2) Now assume we run DELETE operation on "/interfaces/interface" list entry with:
--sil-prio-reverse-for-deletes=true
--sil-delete-children-first=true

This operation will produce the following SIL callback invocation order:

3) Now, assume we run DELETE operation on "/interfaces/interface" list entry with:
--sil-delete-children-first=true
And NO any reversion

This operation will produce the following SIL callback invocation order: