This article gives a quick overview for the callbacks invocation order.

Callbacks on Candidate datastore

Assume we register all the possible callbacks and the edit is complex as possible. The possible invocation order may look as follows, processing on the candidate datastore (before the <commit>):

  1. Transaction Start
  2. Set Order Hook
  3. Set Hook and then Set Order Hook for the added edit, if any
  4. SIL Callbacks (only during Validate Phase)
  5. Transaction Complete

Callbacks on Running datastore

The possible invocation order during the <commit> operation may look as follows, processing on the running datastore (after the <commit>):

  1. Transaction Start
  2. Set Order Hook
  3. SIL Callback (Validate Phase)
  4. Validate Complete
  5. SIL Callback (Apply Phase)
  6. Apply Complete
  7. SIL Callback (Commit Phase)
  8. Transaction Hook
  9. Commit/Rollback Complete
  10. Transaction Complete

Callbacks when target=running 

The <commit> operation is not available if the default target is set to running. Thus, the possible invocation order during the edit operation may look as follows, processing on the running datastore only (the same invocation order will be during Load, Reload and Restart operations):

  1. Transaction Start
  2. Set Order Hook
  3. Set Hook and then Set Order Hook for the added edit, if any
  4. SIL Callback (Validate Phase)
  5. SIL Callback (Apply Phase)
  6. SIL Callback (Commit Phase)
  7. Transaction Hook
  8. Transaction Complete

Callbacks during <validate>

The possible invocation order during the <validate> operation may look as follows, processing on the running datastore only:

  1. Transaction Start
  2. Set Order Hook
  3. SIL Callbacks (only during Validate Phase)
  4. Transaction Complete

Set Hook and Transaction Hook callbacks will not be invoke during explicit <validate> operation and in case of the following netconfd-pro parameters are set to TRUE: 

 --sil-validate-candidate (only relevant to Set Hook) 

 --sil-skip-load

Callbacks during <restore>

The possible invocation order during the <restore> operation may look as follows, processing on the running datastore only:

  1. Transaction Start
  2. Set Order Hook
  3. Set Hook and then Set Order Hook for the added edit, if any
  4. SIL Callback (Validate Phase)
  5. SIL Callback (Apply Phase)
  6. SIL Callback (Commit Phase)
  7. Transaction Hook
  8. Transaction Complete

Hooks callback interaction with EDIT2 callbacks (target=candidate)

In case there are multiple Set-Hook callbacks registered and the callbacks add several extra edits to the transaction with help of add_edit() API the server will have the following interaction with added edits and normal edits that are coming from PDU. Assume we register Set-Hook callback, Set-Order-Hook,  Transaction-Hook and EDIT2 callback for the same list object, for example "ietf-interface" module and "/if:interfaces/if:interface" list object. So any time the "interface" list is getting edited the server invokes Set-Hook callback and adds up an extra "interface" in addition to the regular edit. The following callback invocation order is expected in this case:


Edit on candidate datastore:

  1. Transaction Start
  2. Set Order Hook for "/if:interface[name=vlan1]"
  3. Set-Hook for "/if:interface[name=vlan1]" to add "/if:interface[name=vlan2]"
  4. Set Order Hook for "/if:interface[name=vlan2]"
  5. SIL Callback (Validate Phase) for "/if:interface[name=vlan1]"
  6. SIL Callback (Validate Phase) for "/if:interface[name=vlan2]"
  7. Transaction Complete

Edit on running datastore (after <commit>):

  1. Transaction Start
  2. SIL Callback (Validate Phase) for "/if:interface[name=vlan1]"
  3. SIL Callback (Validate Phase) for "/if:interface[name=vlan2]"
  4. Validate Complete
  5. SIL Callback (Apply Phase) for "/if:interface[name=vlan1]"
  6. SIL Callback (Apply Phase) for "/if:interface[name=vlan2]"
  7. Apply Complete
  8. SIL Callback (Commit Phase) for "/if:interface[name=vlan1]"
  9. SIL Callback (Commit Phase) for "/if:interface[name=vlan2]"
  10. Transaction Hook for "/if:interface[name=vlan1]"
  11. Transaction Hook for "/if:interface[name=vlan2]"
  12. Commit/Rollback Complete
  13. Transaction Complete

Hooks callback interaction with EDIT2 callbacks (target=running)

Assume the same scenario but the default target in this case is set to running. The callbacks invocation order is expected to be:

  1. Transaction Start
  2. Set Order Hook for "/if:interface[name=vlan1]"
  3. Set-Hook for "/if:interface[name=vlan1]" to add "/if:interface[name=vlan2]"
  4. Set Order Hook for "/if:interface[name=vlan2]"
  5. SIL Callback (Validate Phase) for "/if:interface[name=vlan1]"
  6. SIL Callback (Validate Phase) for "/if:interface[name=vlan2]"
  7. SIL Callback (Apply Phase) for "/if:interface[name=vlan1]"
  8. SIL Callback (Apply Phase) for "/if:interface[name=vlan2]"
  9. SIL Callback (Commit Phase) for "/if:interface[name=vlan1]"
  10. SIL Callback (Commit Phase) for "/if:interface[name=vlan2]"
  11. Transaction Hook for "/if:interface[name=vlan1]"
  12. Transaction Hook for "/if:interface[name=vlan2]"
  13. Transaction Complete