Controlling SIL Invocation

There are several extensions and API functions that control how the server will invoke the SIL code and process data in edit requests.

SIL Priority

Warning

  • Use of SIL Priority is not recommended!

  • Use Commit Completeness callbacks if possible to apply and commit system resources after the phase is complete, so edit callback order does not matter.

It is possible for the client to send several edits within a single <edit-config> or <copy-config> request.

Sometimes it is useful to make sure certain data structures are validated and processed before other data structures.

Note

  • SIL priority is represented as an integer from 1 to 255

  • Callbacks with lower values are invoked before higher values

  • The default SIL priority is 255

The SIL callbacks for an "edit" within the server may not correspond exactly to an edit request from the client. For example, a "replace" operation on a container or list may result in some child nodes to be created and other child nodes to be deleted.

The server constructs an edit list based on the client request:

  • Each top-level edit results in an "undo" record

  • Each "undo" record may have nested SIL callbacks. For example, an edit for a container that has multiple child nodes.

  • Each descendant container or list within the "undo" record will result in a nested SIL callback.

  • The leafy child nodes of each container or list are called "child edits". For EDIT2 callbacks, the child edits are gathered together and done all at once (for each parent).

The server orders SIL invocations by sorting the internal edits:

  • If the agt_silcall_delete_first field in the agent profile is set to 'true' then delete operations will be sorted before non-delete operations. If set to 'false' then the edit operation is ignored for the sorting.

  • An edit "undo" record is considered to be a delete if:

    • The undo->editop is a delete (or remove) operation

    • The undo->editop is a "merge" and any child_edits contain a delete operation.

  • SIL callbacks at the same level (sibling nodes) are also sorted

  • For delete operations, the SIL priority may be reversed (see below). If this behavior is configured, and delete operations will be sorted in reverse (highest to lowest). Otherwise they are sorted in the normal fashion (same as non-delete operations).

  • For non-delete operations the SIL callback is sorted from lowest to highest values.

Reverse SIL priority for Delete Operations

The configuration parameter --sil-prio-reverse-for-deletes controls whether SIL priority is reversed for delete operations.

  • If set to "true" the SIL priority for DELETE operations will be reversed.

  • If 'false' then the SIL priority for delete operations will not be reversed. The default is "false".

  • This parameter has no affect on non-delete operations (starting in 21.10-17).

Setting SIL Priority for YANG Objects

The ywx:sil-priority extension can be used to control the order that edits are processed. The SIL priority settings are usually done with an --annotation YANG module, since the client does not need this information.

Deletion of Child Nodes (sil-delete-children-first)

If the client deletes a container of list entries, then the server will normally only invoke the SIL callback for deletion for the container. It may be easier to allow the server to use the SIL callbacks for the child list nodes, to delete a data structure “bottom-up”.

Use the sil-delete-children-first extension to force the server to delete all the child nodes before deleting the parent container.

The sil-delete-children-first extension can be used in any parent node (container or list) and can be used to force the server to invoke the SIL callback for any child node (container, list, leaf, leaf-list, anyxml).

Suppress leafref Validation

Leafref validation involves searching all the “pointed at” leaf instances to make sure that the leafref leaf being validated contains one of the values actually in use. An instance is required to exist for the leafref to be valid.

YANG 1.0 does not support the “require-instance” sub-statement for a leafref definition. In order to force the server to skip this validation step, use the 'agt_cb_skip_leafref_validation' API function.

status_t agt_cb_skip_leafref_validation(const xmlChar *defpath)

Set a previously registered callback as a node that the server should skip leafref validation in order to save processing time.

Parameters:

defpath -- Xpath with default (or no) prefixes

Returns:

status

In the following example, the path /t641-1:B/t641-1:BB/t641-1:fd-mode represents a leafref leaf that will be treated as if the “require-instance false” statement was present in the YANG definition:

Inside SIL init function:

res = agt_cb_register_callback(
    y_test_fd641_1_M_test_fd641_1,
    (const xmlChar *)"/t641-1:B/t641-1:BB/t641-1:fd-mode",
    y_test_fd641_1_R_test_fd641_1,
    test_fd641_1_B_BB_fd_mode_edit);
if (res != NO_ERR) {
    return res;
}

res = agt_cb_skip_leafref_validation(
    (const xmlChar *)"/t641-1:B/t641-1:BB/t641-1:fd-mode");
if (res != NO_ERR) {
    return res;
}