Using Dynamic YANG Module Management in YumaPro SDK : YumaWorks

Requirements:

The yumaworks-system module must be enabled.
The --confdir parameter must be setup correctly to use the configuration update option.

Overview:

The load and unload operations are used together to load and unload a YANG module or a YANG bundle and its associated SIL or SIL-SA library.
The load-bundle and unload-bundle operations are used together to load and unload a bundle of YANG modules and its associated SIL or SIL-SA library.
These operations use the 'nacm:default-deny-all' extension so they can only be used under these conditions:
- --access-control=off is used
- --superuser=user and 'user' is invoking the operation
- NACM rules are configured to allow the operation to be used
- By default, no session can invoke these operations
There is also a <load> operation in yuma-system.yang:
- Use --with-yuma-system=false to disable this module
- If enabled then use the prefix "ysys" to access the yumaworks-system <load> operation

YANG Modules

Load a YANG Module:

Load the module into the server for immediate use.
Save the module configuration for the next reboot with the save-config parameter
Control how the server searches for YANG modules using module search path parameters
The server returns the module revision date loaded.
The <load> operation will succeed even if the confdir is not available. The module config will not be saved across a reboot in this case.
By default this operation will succeed even if no SIL or SIL-SA library is found.
Use the --sil-missing-error=true parameter setting to force an error if a module is loaded but no instrumentation library code is found to load.

<load> Operation Parameters

module	Mandatory leaf	Name of the module to load
revision	Optional leaf-list	Revision date of the module to load. An error is returned if this revision is not found. If not used then the server will use the module search path to find a revision of the specified module.
deviation	Optional leaf-list	Zero or more deviation module names that will be loaded before the module is loaded. (Optional)
save-config	Optional leaf	Save the module configuration so it will be loaded after a reboot. This is recommended if configuration is saved from the module. Otherwise an 'unknown-namespace' error will occur when the configuration is validated upon the next reboot. [default: false]

Example:

netconfd-pro startup:

> netconfd-pro --confdir=~/myconfig --superuser=admin

yangcli-pro request:

admin@server1> ysys:load module=test2 save-config=true

XML Request:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="1"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <load xmlns="http://yumaworks.com/ns/yumaworks-system">
  <module>test2</module>
  <save-config>true</save-config>
 </load>
</rpc>

XML Response:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="1"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <mod-revision xmlns="http://yumaworks.com/ns/yumaworks-system">2008-10-15</mod-revision>
</rpc-reply>

If the server returns this data instead of an <rpc-error> then the load operation succeeded.

The contents of the file $HOME/myconfig/test2.conf, generating by this operation because save-config=true.

# generated by netconfd-pro at 2019-08-23T20:21:39Z
netconfd-pro {
module test2
}

Notifications

If notifications are enabled and IETF system-notifications are enabled (the default) then a <netconf-capability-change> notification will be sent the NETCONF stream.

Notification example:

<?xml version="1.0" encoding="UTF-8"?>
 <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2019-08-24T01:48:44Z</eventTime>
  <netconf-capability-change xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-notifications">
   <changed-by>
    <username>admin</username>
    <session-id>3</session-id>
    <source-host>127.0.0.1</source-host>
   </changed-by>
   <added-capability>http://netconfcentral.org/ns/test2?module=test2&amp;revision=2008-10-15</added-capability>
  </netconf-capability-change>
 </notification>

The yang-library-change notification from ietf-yang-library.yang is also generated when a module is added:

<?xml version="1.0" encoding="UTF-8"?>
 <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2019-08-24T17:52:06Z</eventTime>
  <yang-library-change xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
   <module-set-id>3862</module-set-id>
  </yang-library-change>
 </notification>

Unload a YANG Module:

Unload a YANG module that was previously loaded into the server.
Remove the module configuration from the server with the delete-config parameter
The server returns <ok> if the operation succeeded or <rpc-error> if not.
The <unload> operation will fail if other modules are loaded that import the specified module.

<unload> Operation Parameters

module	Mandatory leaf	Name of the module to unload
delete-config	Optional leaf	Delete the module configuration file so it will not be loaded after a reboot. This only affects modules loaded with the save-config option so a .conf file exists in the confdir to delete. [default: false]

Example:

netconfd-pro startup:

> netconfd-pro --confdir=~/myconfig --superuser=admin

yangcli-pro request:

admin@server1> unload module=test2 delete-config=true

XML Request:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="2"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <unload xmlns="http://yumaworks.com/ns/yumaworks-system">
  <module>test2</module>
  <delete-config>true</delete-config>
 </unload>
</rpc>

If the server returns <ok/> instead of an <rpc-error> then the unload operation succeeded.

The file $HOME/myconfig/test2.conf is deleted by this operation because delete-config=true.

Notifications

If notifications are enabled and IETF system-notifications are enabled (the default) then a <netconf-capability-change> notification will be sent the NETCONF stream.

Notification example:

<?xml version="1.0" encoding="UTF-8"?>
 <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2019-08-24T17:52:12Z</eventTime>
  <netconf-capability-change xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-notifications">
   <changed-by>
    <username>admin</username>
    <session-id>3</session-id>
    <source-host>127.0.0.1</source-host>
   </changed-by>
   <deleted-capability>http://netconfcentral.org/ns/test2?module=test2&amp;revision=2008-10-15</deleted-capability>
  </netconf-capability-change>
 </notification>

The yang-library-change notification from ietf-yang-library.yang is also generated when a module is removed:

<?xml version="1.0" encoding="UTF-8"?>
 <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2019-08-24T17:52:12Z</eventTime>
  <yang-library-change xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
   <module-set-id>3746</module-set-id>
  </yang-library-change>
 </notification>

YANG Bundles

Load a YANG Bundle:

Load the bundle into the server for immediate use.
Save the module configuration for the next reboot with the save-config parameter
Control how the server searches for YANG bundles using module search path parameters
The server returns <ok> or <rpc-error>
The <load-bundle> operation will succeed even if the confdir is not available. The bundle config will not be saved across a reboot in this case.
This operation will succeed even if no SIL or SIL-SA library is found.
If the server is built with WITH_YCONTROL=1, then the server will assume that a SIL-SA bundle is being used of no SIL library found. It will save the load-bundle request in case a subsystem connects to the server and loads a SIL-SA library.

<load-bundle> Operation Parameters

module	Mandatory leaf	Name of the bundle to load
deviation	Optional leaf-list	Zero or more deviation module names that will be loaded before the bundle is loaded. (Optional)
save-config	Optional leaf	Save the bundle configuration so it will be loaded after a reboot. This is recommended if configuration is saved from the bundle. Otherwise an 'unknown-namespace' error will occur when the configuration is validated upon the next reboot. [default: false]

Example:

Create a SIL bundle with modules 'test3', 'test4', 'test5'

> make_sil_bundle bundle1 test3 test4 test5

netconfd-pro startup:

> netconfd-pro --confdir=~/myconfig --superuser=admin

yangcli-pro request:

admin@server1> load-bundle bundle=bundle1 save-config=true

XML Request:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="2"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <load-bundle xmlns="http://yumaworks.com/ns/yumaworks-system">
  <bundle>bundle1</bundle>
  <save-config>true</save-config>
 </load-bundle>
</rpc>

If the server returns <ok/> instead of an <rpc-error> then the load-bundle operation succeeded.

The contents of the file $HOME/myconfig/bundle1.conf, generating by this operation because save-config=true.

# generated by netconfd-pro at 2019-08-24T18:18:19Z
netconfd-pro {
bundle bundle1
}

Notifications

If notifications are enabled and IETF system-notifications are enabled (the default) then a <netconf-capability-change> notification will be sent the NETCONF stream.

A notification will be sent for each module in the bundle that was loaded.

Notification example:

<?xml version="1.0" encoding="UTF-8"?>
 <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2019-08-24T18:18:19Z</eventTime>
  <netconf-capability-change xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-notifications">
   <changed-by>
    <username>admin</username>
    <session-id>3</session-id>
    <source-host>127.0.0.1</source-host>
   </changed-by>
   <added-capability>http://netconfcentral.org/ns/test3?module=test3&amp;revision=2008-10-19</added-capability>
  </netconf-capability-change>
 </notification>

<?xml version="1.0" encoding="UTF-8"?>
 <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2019-08-24T18:18:19Z</eventTime>
  <netconf-capability-change xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-notifications">
   <changed-by>
    <username>admin</username>
    <session-id>3</session-id>
    <source-host>127.0.0.1</source-host>
   </changed-by>
   <added-capability>http://netconfcentral.org/ns/test4?module=test4&amp;revision=2009-09-09</added-capability>
  </netconf-capability-change>
 </notification>

<?xml version="1.0" encoding="UTF-8"?>
 <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2019-08-24T18:18:19Z</eventTime>
  <netconf-capability-change xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-notifications">
   <changed-by>
    <username>admin</username>
    <session-id>3</session-id>
    <source-host>127.0.0.1</source-host>
   </changed-by>
   <added-capability>http://netconfcentral.org/ns/test5?module=test5&amp;revision=2008-11-20</added-capability>
  </netconf-capability-change>
 </notification>

The yang-library-change notification from ietf-yang-library.yang is also generated when a bundle is added.

The server will send one notification for each module added. (Showing just 1, since they are the same except module-set-id value)

<?xml version="1.0" encoding="UTF-8"?>
 <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2019-08-24T17:52:06Z</eventTime>
  <yang-library-change xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
   <module-set-id>3862</module-set-id>
  </yang-library-change>
 </notification>

Unload a YANG Bundle:

Unload a YANG bundle that was previously loaded into the server.
Remove the bundle configuration from the server with the delete-config parameter
The server returns <ok> if the operation succeeded or <rpc-error> if not.
The <unload-bundle> operation will fail if other modules are loaded that import any of the modules in the specified bundle.

<unload-bundle> Operation Parameters

bundle	Mandatory leaf	Name of the bundle to unload
delete-config	Optional leaf	Delete the bundle configuration file so it will not be loaded after a reboot. This only affects bundles loaded with the save-config option so a .conf file exists in the confdir to delete. [default: false]

Example:

netconfd-pro startup:

> netconfd-pro --confdir=~/myconfig --superuser=admin

yangcli-pro request:

admin@server1> unload-bundle bundle=bundle1 delete-config=true

XML Request:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="2"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <unload xmlns="http://yumaworks.com/ns/yumaworks-system">
  <module>test2</module>
  <delete-config>true</delete-config>
 </unload>
</rpc>

If the server returns <ok/> instead of an <rpc-error> then the unload operation succeeded.

The file $HOME/myconfig/bundle1.conf is deleted by this operation because delete-config=true.

Notifications

If notifications are enabled and IETF system-notifications are enabled (the default) then a <netconf-capability-change> notification will be sent the NETCONF stream.

A notification will be sent for each module in the bundle that was loaded.

Notification example:

<?xml version="1.0" encoding="UTF-8"?>
 <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2019-08-24T18:51:45Z</eventTime>
  <netconf-capability-change xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-notifications">
   <changed-by>
    <username>admin</username>
    <session-id>3</session-id>
    <source-host>127.0.0.1</source-host>
   </changed-by>
   <deleted-capability>http://netconfcentral.org/ns/test3?module=test3&amp;revision=2008-10-19</deleted-capability>
  </netconf-capability-change>
 </notification>

<?xml version="1.0" encoding="UTF-8"?>
 <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2019-08-24T18:51:45Z</eventTime>
  <netconf-capability-change xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-notifications">
   <changed-by>
    <username>admin</username>
    <session-id>3</session-id>
    <source-host>127.0.0.1</source-host>
   </changed-by>
   <deleted-capability>http://netconfcentral.org/ns/test4?module=test4&amp;revision=2009-09-09</deleted-capability>
  </netconf-capability-change>
 </notification>

<?xml version="1.0" encoding="UTF-8"?>
 <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2019-08-24T18:51:45Z</eventTime>
  <netconf-capability-change xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-notifications">
   <changed-by>
    <username>andy</username>
    <session-id>3</session-id>
    <source-host>127.0.0.1</source-host>
   </changed-by>
   <deleted-capability>http://netconfcentral.org/ns/test5?module=test5&amp;revision=2008-11-20</deleted-capability>
  </netconf-capability-change>
 </notification>

The yang-library-change notification from ietf-yang-library.yang is also generated when a bundle is removed.

The server will send one notification for each module removed. (Showing just 1, since they are the same except module-set-id value)

<?xml version="1.0" encoding="UTF-8"?>
 <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2019-08-24T18:18:19Z</eventTime>
  <yang-library-change xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
   <module-set-id>3955</module-set-id>
  </yang-library-change>
 </notification>

YumaWorks

Please try our Online Documentation first.

How can we help you today?

Dynamic Module Management Print

Please try our Online Documentation first.

How can we help you today?

Dynamic Module Management Print

Related Articles