X-Git-Url: https://git.opendaylight.org/gerrit/gitweb?a=blobdiff_plain;f=tests%2Fhoneynode%2F2.2.1%2Fhoneynode-plugin-impl%2Fsrc%2Fmain%2Fresources%2Fhoneycomb-minimal-resources%2Fconfig%2Fyang%2Fcommon%2Forg-openroadm-manifest-file%402017-12-15.yang;fp=tests%2Fhoneynode%2F2.2.1%2Fhoneynode-plugin-impl%2Fsrc%2Fmain%2Fresources%2Fhoneycomb-minimal-resources%2Fconfig%2Fyang%2Fcommon%2Forg-openroadm-manifest-file%402017-12-15.yang;h=6f74fcd9198717613b25d11b13501efec0df5bfa;hb=b90fdacec82f92e07d14ed1df31e3fe53275c676;hp=0000000000000000000000000000000000000000;hpb=1030996d2cfc0cec3c6c2b5d8da37c6188122372;p=transportpce.git diff --git a/tests/honeynode/2.2.1/honeynode-plugin-impl/src/main/resources/honeycomb-minimal-resources/config/yang/common/org-openroadm-manifest-file@2017-12-15.yang b/tests/honeynode/2.2.1/honeynode-plugin-impl/src/main/resources/honeycomb-minimal-resources/config/yang/common/org-openroadm-manifest-file@2017-12-15.yang new file mode 100644 index 000000000..6f74fcd91 --- /dev/null +++ b/tests/honeynode/2.2.1/honeynode-plugin-impl/src/main/resources/honeycomb-minimal-resources/config/yang/common/org-openroadm-manifest-file@2017-12-15.yang @@ -0,0 +1,933 @@ +module org-openroadm-manifest-file { + namespace "http://org/openroadm/manifest-file"; + prefix org-openroadm-manifest-file; + + organization + "Open ROADM MSA"; + contact + "OpenROADM.org"; + description + "YANG definitions of sw-manifest-file + + Copyright of the Members of the Open ROADM MSA Agreement dated (c) 2017, + AT&T Intellectual Property. All other rights reserved. + + Redistribution and use in source and binary forms, with or without modification, + are permitted provided that the following conditions are met: + + * Redistributions of source code must retain the above copyright notice, this + list of conditions and the following disclaimer. + * Redistributions in binary form must reproduce the above copyright notice, + this list of conditions and the following disclaimer in the documentation and/or + other materials provided with the distribution. + * Neither the Members of the Open ROADM MSA Agreement nor the names of its + contributors may be used to endorse or promote products derived from this software + without specific prior written permission. + + THIS SOFTWARE IS PROVIDED BY THE MEMBERS OF THE OPEN ROADM MSA AGREEMENT ''AS IS'' + AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED + WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + IN NO EVENT THE MEMBERS OF THE OPEN ROADM MSA AGREEMENT BE LIABLE FOR ANY DIRECT, + INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, + OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, + WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + POSSIBILITY OF SUCH DAMAGE. + + Also contains code components extracted from IETF netconf. These code components + are copyrighted and licensed as follows: + + Copyright (c) 2016 IETF Trust and the persons identified as the document authors. + All rights reserved. + + This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating + to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents carefully, as they + describe your rights and restrictions with respect to this document. Code Components + extracted from this document must include Simplified BSD License text as described in + Section 4.e of the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License."; + + revision 2017-12-15 { + description + "Version 2.2"; + } + revision 2017-09-29 { + description + "Version 2.1"; + reference "This module serves as the manifest file reference."; + } + + identity manifest-commands { + description + "base identity for defining manifest-commands."; + } + + identity download-file { + base manifest-commands; + description + "download-file (transfer from OWB-C to Device)"; + } + + identity upload-file { + base manifest-commands; + description + "upload-file (transfer from Device to OWB-C)"; + } + + identity delete-file { + base manifest-commands; + description + "delete-file from device"; + } + + identity sw-manifest-commands { + base manifest-commands; + description + "base identity for defining manifest-commands specific to sw-manifest."; + } + + identity sw-stage { + base sw-manifest-commands; + description + "sw-stage sw-manifest-command"; + } + + identity sw-activate { + base sw-manifest-commands; + description + "sw-activate sw-manifest-command"; + } + + identity db-backup-manifest-commands { + base manifest-commands; + description + "base identity for defining manifest-commands specific to db-backup-manifest."; + } + + identity db-backup { + base db-backup-manifest-commands; + description + "db-backup db-backup-manifest-command"; + } + + identity db-restore-manifest-commands { + base manifest-commands; + description + "base identity for defining manifest-commands specific to db-restore-manifest."; + } + + identity db-restore { + base db-restore-manifest-commands; + description + "db-restore db-restore-manifest-command"; + } + + identity db-activate { + base db-restore-manifest-commands; + description + "db-activate db-restore-manifest-command"; + } + + grouping base-manifest { + description + "base set of variables in all manifest files"; + leaf vendor { + type string; + mandatory true; + description + "This field should match the /org-openroadm-device/info/vendor. + It is assumed that the vendor value does not change during the + processing of the manifest file. + + The controller agent would use the vendor and model to find the + manifest for an Open ROADM NE. The controller agent would also + use the vendor and model to validate that this is a valid manifest + for the Open ROADM NE. + "; + } + leaf model { + type string; + mandatory true; + description + "This field should match the /org-openroadm-device/info/model. + It is assumed that the model value does not change during the + processing of the manifest file. + + The controller agent would use the vendor and model to find the + manifest for an Open ROADM NE. The controller agent would also + use the vendor and model to validate that this is a valid manifest + for the Open ROADM NE. + "; + } + leaf sw-version { + type string; + description + "This field should match the + /org-openroadm-device/info/softwareVersion. + This is the value in the info tree AFTER an upgrade. + "; + } + leaf global-async-timeout { + type uint16; + default "900"; + description + "global-async-timeout - time in seconds to wait for command processing to + complete. + + Upon timeout, the controller may either: + - assume success; + - assume failure; + - poll the device to determine success/failure of the operation + + This global-async-timeout applies to any asynchronous command. + "; + } + leaf global-sync-timeout { + type uint16; + description + "global-sync-timeout - time in seconds to wait for the rpc response for + synchronous commands. + + This global-sync-timeout applies to any synchronous command. + + Upon timeout, the controller may either: + - assume success; + - assume failure; + - poll the device to determine success/failure of the operation + + No default is modeled; if not provided, defaults to the global + timeout supported by the controller for rpc responses. + "; + } + } + + grouping timeout-command { + description + "timeout-command is to be used by any manifest command supporting a timeout"; + leaf timeout { + type uint16; + description + "See command for additional details. + if command is async, + - overrides the global-async-timeout; + - defaults to the global-async-timeout if not provided. + if command is sync, + - overrides the global-sync-timeout; + - defaults to the global-sync-timeout if not provided. + "; + } + } + + grouping is-async-command { + description + "is-async-command is to be supported by all manifest commands even if only + supported as sync or async. In such cases, a must statement should be + included to limit support to either sync or async."; + leaf is-async { + type boolean; + default "true"; + description + "command can be supported as either an async or sync command by a vendor. + When supported as a sync command, the OWB-C will determine the success/failure + of the command based on the RPC response instead of waiting for transient + notifications from the device."; + } + } + + grouping transfer-command { + description + "transfer-command defines the common set of variables used by download-file + and upload-file"; + leaf remote-filename { + type string; + mandatory true; + description + "See command for detailed description."; + } + leaf local-file-path { + type string; + mandatory true; + description + "See command for detailed description."; + } + uses timeout-command; + uses is-async-command; + } + + grouping file-command { + description + "file-command is used by all manifest files needing a filename"; + leaf filename { + type string; + description + "filename is mandatory for delete-file; optional otherwise. + See command for detailed description."; + } + } + + grouping command-reboot { + description + "command-reboot is used by manifest commands which result in a + device restart."; + leaf auto-reboot { + type uint16; + mandatory true; + description + "See command for detailed description."; + } + } + + grouping download-file-command { + description + "down-file-command"; + container download-file { + when "../command = 'download-file'"; + description + "Transfer a file from the SFTP server to the device. + format: download-file remote-filename local-file-path [timeout] + where + remote-filename is the filename of the file to transfer on the SFTP + server. The filename can include a relative path that represents the + subdirectory structure of the vendor's software directory. This file + (and optional path) must exist in the software release directory on + the SFTP server. + + local-file-path is the local path and filename to transfer the file on + the device. + + timeout - see timeout-command grouping for basic details; + if command is async, + - Receipt of an in-progress (version 2) + transfer-notification resets the timeout. + + Maps to the transfer rpc with + action = download + local-file-path = local-file-path + remote-file-path = + sftp://user:password@host[:port]/path/remote-filename + + The remote-file-path attribute on the transfer command would be + constructed by the software download agent by appending the sftp URL + (which includes username, password, host, port, and path to the + software release directory) with the remote_filename. + + In the context of the transfer, remote is the SFTP server (e.g., located + on the software download agent) and local is on the Open ROADM device. + + Expected notifications: transfer-notification + "; + uses transfer-command; + } + } + + grouping upload-file-command { + description + "upload-file-command"; + container upload-file { + when "../command = 'upload-file'"; + description + "Transfer a file from the device to the SFTP server. + format: upload-file remote-filename local-file-path [timeout] + where + remote-filename is the filename of the file to receive the upload + on the SFTP server. The filename can include a relative path that + represents the subdirectory structure of the vendor's software + directory. + + local-file-path is the local path and filename of the file on + the device to be uploaded to the SFTP server. This file must exist on + the device. + + timeout - see timeout-command grouping for basic details; + if command is async, + - Receipt of an in-progress (version 2) + transfer-notification resets the timeout. + + Maps to the transfer rpc with + action = upload + local-file-path = local-file-path + remote-file-path = + sftp://user:password@host[:port]/path/remote-filename + + The remote-file-path attribute on the transfer command would be + constructed by the software download agent by appending the sftp URL + (which includes username, password, host, port, and path to the + software release directory) with the remote_filename. + + In the context of the transfer, remote is the SFTP server (e.g., located + on the software download agent) and local is on the Open ROADM device. + + Expected notifications: transfer-notification + "; + uses transfer-command; + } + } + + grouping delete-file-command { + description + "delete-file-command"; + container delete-file { + when "../command = 'delete-file'"; + must "is-async != 'false'" { + error-message "delete-file is only supported as sync command"; + } + description + "Delete a file from the device's file system. + format: delete-file filename [timeout] + where + filename is the filename to be deleted from the device. The filename + may include path information. + + timeout - overrides the global-sync-timeout; defaults to the + global-sync-timeout if not provided. + + Maps to the delete-file rpc: + delete-file filename + "; + uses file-command { + refine "filename" { + mandatory true; + } + } + uses timeout-command; + uses is-async-command; + } + } + + grouping sw-stage-command { + description + "sw-stage-command"; + container sw-stage { + when "../command = 'sw-stage'"; + description + "Stage a file in the device. The details of what a device does during + the staging operation is vendor specific. However, the vendor may + initiate additional file transfers from the SFTP server during the + staging operation. It is expected that the files will only be + transferred from the software release directory. + + format: sw-stage [filename] [timeout] + where + filename is the filename of the file to stage. If filename is not + provided, the software download application will send the sw-stage + command without a filename. + + timeout - overrides the global-async-timeout; defaults to the + global-async-timeout if not provided. + + + Maps to the sw-stage rpc: + sw-stage [filename] + + Expected notifications: sw-stage-notification + "; + uses file-command; + uses timeout-command; + uses is-async-command; + } + } + + grouping sw-activate-command { + description + "sw-activate-command"; + container sw-activate { + when "../command = 'sw-activate'"; + must "is-async != 'true'" { + error-message "sw-activate is only supported as async command"; + } + description + "Activate a software load in a device. The details of what a device does + during the activation phase is vendor specific. The device initiates + an automatic reboot as part of the activation. + + format: sw-activate version [validation-timer] [timeout] auto-reboot + where: + version: The version of software that is being activated. (The current + YANG model indicates that version is optional; however, version should + be a mandatory attribute of the sw-activate command in the manifest + file). + + validation-timer: Validation timer setting for the software activation. + Format is expected to be in the form HH-MM-SS per the YANG model. The + software download application expects this format in order to treat + 00-00-00 and no validation timer as the same use case. + + timeout - overrides the global-async-timeout; defaults to the + global-async-timeout if not provided. This timer begins as soon as the + sw-activate processing begins. timeout must be greater than the + auto-reboot time. + + auto-reboot: time (in seconds) to wait to for the device to reboot. + This is the device restart time (e.g. the length of time from device + comm loss until the device is ready for login). This timer begins when + the controller detects the comm-loss from the device. If login is not + successful when this timer expires, the sw-activate is failed. + + NOTE: if controller swdl application is not doing the login directly, + the controller may need to augment the auto-reboot timer to account for + the login time. + + Maps to the sw-activate rpc: + sw-activate version [validationTimer] + + Expected notifications: sw-activate-notification + When no validation timer (or validation-timer = 00-00-00), two + notifications will be expected: one for activate, the other for + commit. Otherwise, only the activate notification is expected. + + NOTE: the sw-activate-notifications (for activate) may be received + before or after the reboot; it is assumed the sw-activate-notification + (for commit) always occurs after the reboot. Any polling due to missed + sw-activate-notifications (activate and/or commit) should not be done + until after the reboot login; processing of sw-activate does not + complete until after receipt of the notifications and the reboot login. + "; + leaf version { + type string; + mandatory true; + description + "Although version is optional in the sw-activate rpc, it is + mandatory in the manifest file command."; + } + leaf validation-timer { + type string; + description + "hh-mm-ss"; + } + uses timeout-command; + uses command-reboot; + uses is-async-command; + } + } + + grouping db-backup-command { + description + "db-backup-command"; + container db-backup { + when "../command = 'db-backup'"; + description + "Perform a database backup on the device. + + format: db-backup [filename] [timeout] + where + filename is the filename of the backup file to be generated on the + device. If filename is not provided, the database backup application + will send the db-backup command without a filename. It's possible the + filename will not be statically provided in the manifest file, but + provided by the database backup application. + + timeout - see timeout-command grouping for basic details; + + Maps to the db-backup rpc: + db-backup [filename] + + Expected notifications: db-backup-notification + "; + uses file-command; + uses timeout-command; + uses is-async-command; + } + } + + grouping db-restore-command { + description + "db-restore-command"; + container db-restore { + when "../command = 'db-restore'"; + description + "Perform a database restore on the device. + + format: db-restore [filename] [node-id-check] [timeout] + where + filename is the filename of the file to be restored on the + device. If filename is not provided, the database restore application + will send the db-restore command without a filename. It's possible the + filename will not be statically provided in the manifest file, but + provided by the database restore application. + + node-id-check is a boolean indicating whether sysNameCheck is required. + + timeout - see timeout-command grouping for basic details; + + Maps to the db-restore rpc: + db-restore [filename] [nodeIDCheck] + + Expected notifications: db-restore-notification + "; + uses file-command; + leaf node-id-check { + type string; + default "true"; + description + "Defined as an string here so that manifest file can parameterize + the value for user input. __NODE-ID-CHECK is used for that purpose. Other valid + values are true or false. Maps to a boolean value in the rpc invocation."; + } + uses timeout-command; + uses is-async-command; + } + } + + grouping db-activate-command { + description + "db-activate-command"; + container db-activate { + when "../command = 'db-activate'"; + must "is-async != 'true'" { + error-message "db-activate is only supported as async command"; + } + description + "Activate a database on a device. The details of what a device does + during the activation phase is vendor specific. The device initiates + an automatic reboot as part of the activation. + + format: db-activate [rollback-timer] [timeout] auto-reboot + where: + rollback-timer: Rollback timer setting for the database activation. + Format is expected to be in the form HH-MM-SS per the YANG model. The + database activation application expects this format in order to treat + 00-00-00 and no validation timer as the same use case. + + timeout - overrides the global-async-timeout; defaults to the + global-async-timeout if not provided. This timer begins as soon as the + db-activate processing begins. timeout must be greater than the + auto-reboot time. + + auto-reboot: time (in seconds) to wait to for the device to reboot. + This is the device restart time (e.g. the length of time from device + comm loss until the device is ready for login). This timer begins when + the controller detects the comm-loss from the device. If login is not + successful when this timer expires, the db-activate is failed. + + NOTE: if controller database application is not doing the login + directly, the controller may need to augment the auto-reboot timer to + account for the login time. + + Maps to the db-activate rpc: + db-activate [rollBackTimer] + + Expected notifications: db-activate-notification + When no rollback timer (or rollback-timer = 00-00-00), two + notifications will be expected: one for activate, the other for + commit. Otherwise, only the activate notification is expected. + + NOTE: the db-activate-notifications (for activate) may be received + before or after the reboot; it is assumed the db-activate-notification + (for commit) always occurs after the reboot. Any polling due to missed + db-activate-notifications (activate and/or commit) should not be done + until after the reboot login; processing of db-activate does not + complete until after receipt of the notifications and the reboot login. + "; + leaf rollback-timer { + type string; + description + "hh-mm-ss"; + } + uses timeout-command; + uses command-reboot; + uses is-async-command; + } + } + + container sw-manifest { + presence "The sw-manifest instructions for swdl operations have been defined."; + description + "The manifest file provides instructions to a software download + application to download and install a new software load into a vendor’s + equipment. + + Software download files + All vendor files for a software release should be stored in a + separate directory. A unique directory would be used for each vendor, + model and software release combination. This directory and all files in + that directory will be accessible by the SFTP server. + The software directory can be flat or hierarchical with + subdirectories. The manifest file should be in the root directory of the + software directory. + A software directory must contain files for one and only one + software release. + + Manifest file name + Each software release directory shall contain a manifest file for + that release. The filename for the manifest file shall be sw-manifest.json. + "; + uses base-manifest { + refine "sw-version" { + mandatory true; + } + } + list instruction-set { + key "index"; + description + "The instruction set for a list of sw-versions that can be upgraded to + the sw-version specified at the top of the manifest file."; + leaf index { + type uint8; + description + "The index for this instruction set."; + } + leaf-list from-sw-version { + type string; + description + "The optional list of sw-versions that can be upgraded to the + sw-version specified at the top of the sw-manifest file. + + If not specified, this instruction set is used to upgrade from + any sw-version to the sw-version specified at the top of the + sw-manifest file. + + If multiple instruction sets are provided, from-sw-version + should always be defined."; + } + leaf is-commit-sw-activate-async { + type boolean; + default "true"; + description + "Is cancel-validation-timer (accept = true) supported as an + async or sync command on the device? If supported as sync, the rpc response + is used to determine success/failure instead of waiting for transient notifications + of the result. + NOTE: cancel-validation-timer (accept = false) requires a reboot so is + always considered async"; + } + leaf cancel-validation-timer-async-timeout { + type uint16; + description + "timeout value to use for cancel-validation-timer when supported as + an async command. If not specified, the global-async-timeout is used."; + } + leaf cancel-validation-timer-sync-timeout { + type uint16; + description + "timeout value to use for cancel-validation-timer (accept = true) when + supported as a sync command. If not specified, the global-sync-timeout + is used."; + } + container sw-manifest-commands { + description + "The ordered list of commands to be processed. Since some yang + implementations do not support ordered-by user, the list is also + indexed by command-order. The commands should be processed + in the order of command-order. + + Processing moves to the next command when: + 1. command is synchronous and rpc returns a successful result. + 2. command is asynchronous, the rpc returns a successful result, + and + 2.1 expected successful notification(s) have been received; or + 2.2 timeout occurs. + \t\t + Processing of the manifest file is aborted when: + 1. command is synchronous and rpc returns a failed result. + 2. command is asynchronous, and: + 2.1 the rpc returns a failed result; or + 2.2 a failed notification is received; or + 2.3 timeout occurs. + \t\t + NOTE: behavior for timeouts (synchronous or asynchronous) may depend upon + controller implementation per command. It may be considered either: + - as a successful result + - as a failed result + - as a success or failure based on polling the device + "; + list sw-manifest-command { + key "command-order"; + ordered-by user; + description + "The list of commands to be processed."; + leaf command-order { + type uint8; + description + "The order in which commands should be processed."; + } + leaf command { + type identityref { + base sw-manifest-commands; + } + mandatory true; + description + "The command to be processed."; + } + uses download-file-command; + uses delete-file-command; + uses sw-stage-command; + uses sw-activate-command; + } + } + } + } + container db-backup-manifest { + presence "The db-backup-manifest template for db-backup operations has been defined."; + description + "The manifest file provides instructions to a database operations + application to backup the database on a device. + + Since the files used for these operations are likely user selected, + these manifest files are more likely used by the controller as a + template to control the overall flow of a backup operation and provide + a means of providing customized timeout values. + + The following strings will be recognized as parameters to be replaced + by the user selected values: __LOCAL-FILE-PATH, __REMOTE-FILENAME. + + Manifest file name + Each vendor/model combination can have a separate manifest file + defined for backup. These shall be named db-backup-manifest.json. + "; + uses base-manifest; + container db-backup-manifest-commands { + description + "The ordered list of commands to be processed. Since some yang + implementations do not support ordered-by user, the list is also + indexed by command-order. The commands should be processed + in the order of command-order. + + Processing moves to the next command when: + 1. command is synchronous and rpc returns a successful result. + 2. command is asynchronous, the rpc returns a successful result, + and + 2.1 expected successful notification(s) have been received; or + 2.2 timeout occurs. + + Processing of the manifest file is aborted when: + 1. command is synchronous and rpc returns a failed result. + 2. command is asynchronous, and: + 2.1 the rpc returns a failed result; or + 2.2 a failed notification is received; or + 2.3 timeout occurs. + + NOTE: behavior for timeouts (synchronous or asynchronous) may depend upon + controller implementation per command. It may be considered either: + - as a successful result + - as a failed result + - as a success or failure based on polling the device + "; + list db-backup-manifest-command { + key "command-order"; + ordered-by user; + description + "The list of commands to be processed."; + leaf command-order { + type uint8; + description + "The order in which commands should be processed."; + } + leaf command { + type identityref { + base db-backup-manifest-commands; + } + mandatory true; + description + "The command to be processed."; + } + uses upload-file-command; + uses delete-file-command; + uses db-backup-command; + } + } + } + container db-restore-manifest { + presence "The db-restore-manifest template for db-restore operations has been defined."; + description + "The manifest file provides instructions to a database operations + application to restore the database on a device. + + Since the files used for these operations are likely user selected, + these manifest files are more likely used by the controller as a + template to control the overall flow of a restore operation and provide + a means of providing customized timeout and auto-reboot values. + + The following strings will be recognized as parameters to be replaced + by the user selected values: __LOCAL-FILE-PATH, __REMOTE-FILENAME, + __NODE-ID-CHECK. + + Manifest file name + Each vendor/model combination can have a separate manifest file + defined for restore. These shall be named db-restore-manifest.json. + "; + uses base-manifest; + leaf is-commit-db-activate-async { + type boolean; + default "true"; + description + "Is cancel-rollback-timer (accept = true) supported as an + async or sync command on the device? If supported as sync, the rpc response + is used to determine success/failure instead of waiting for transient notifications + of the result. + NOTE: cancel-rollback-timer (accept = false) requires a reboot so is + always considered async"; + } + leaf cancel-rollback-timer-async-timeout { + type uint16; + description + "timeout value to use for cancel-rollback-timer when supported as + an async command. If not specified, the global-async-timeout is used."; + } + leaf cancel-rollback-timer-sync-timeout { + type uint16; + description + "timeout value to use for cancel-rollback-timer (accept = true) when + supported as a sync command. If not specified, the global-sync-timeout + is used."; + } + leaf database-init-sync-timeout { + type uint16; + description + "timeout value to use for database-init command. If not specified, + the global-sync-timeout is used."; + } + container db-restore-manifest-commands { + description + "The ordered list of commands to be processed. Since some yang + implementations do not support ordered-by user, the list is also + indexed by command-order. The commands should be processed + in the order of command-order. + + Processing moves to the next command when: + 1. command is synchronous and rpc returns a successful result. + 2. command is asynchronous, the rpc returns a successful result, + and + 2.1 expected successful notification(s) have been received; or + 2.2 timeout occurs. + + Processing of the manifest file is aborted when: + 1. command is synchronous and rpc returns a failed result. + 2. command is asynchronous, and: + 2.1 the rpc returns a failed result; or + 2.2 a failed notification is received; or + 2.3 timeout occurs. + + NOTE: behavior for timeouts (synchronous or asynchronous) may depend upon + controller implementation per command. It may be considered either: + - as a successful result + - as a failed result + - as a success or failure based on polling the device + "; + list db-restore-manifest-command { + key "command-order"; + ordered-by user; + description + "The list of commands to be processed."; + leaf command-order { + type uint8; + description + "The order in which commands should be processed."; + } + leaf command { + type identityref { + base db-restore-manifest-commands; + } + mandatory true; + description + "The command to be processed."; + } + uses download-file-command; + uses delete-file-command; + uses db-restore-command; + uses db-activate-command; + } + } + } +}