module org-openroadm-manifest-file { namespace "http://org/openroadm/manifest-file"; prefix org-openroadm-manifest-file; import org-openroadm-common-node-types { prefix org-openroadm-common-node-types; revision-date 2021-05-28; } import org-openroadm-common-types { prefix org-openroadm-common-types; revision-date 2023-05-26; } 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, 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 2023-05-26 { description "Version 13.1"; } revision 2022-12-09 { description "Version 12.1"; } revision 2021-05-28 { description "Version 9.1"; } revision 2021-03-26 { description "Version 9.0"; } revision 2020-12-11 { description "Version 8.1"; } revision 2020-09-25 { description "Version 8.0"; } revision 2020-03-27 { description "Version 7.0.0"; } revision 2019-11-29 { description "Version 6.1.0"; } revision 2018-11-30 { description "Version 4.1.0"; } revision 2018-05-30 { description "Version 3.1.0"; } 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."; } typedef timer-ref-enum { type enumeration { enum before-reboot { value 1; description "Before reboot"; } enum after-reboot { value 2; description "After reboot"; } } description "Qualifier for timer starts before or after reboot"; } identity manifest-commands { description "base identity for defining manifest-commands."; } identity file-manifest-commands { base manifest-commands; description "base identity for defining manifest-commands specific to file operations."; } identity download-file { base file-manifest-commands; description "download-file (transfer from OWB-C to Device)"; } identity upload-file { base file-manifest-commands; description "upload-file (transfer from Device to OWB-C)"; } identity delete-file { base file-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 cancel-validation-timer { base sw-manifest-commands; description "cancel-validation-timer 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"; } identity cancel-rollback-timer { base db-restore-manifest-commands; description "cancel-rollback-timer 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-list additional-models { type string; description "Used to list additional equipment models supported by the manifest file, the model attribute has been maintained for backward compatibility. "; } leaf-list node-type { type org-openroadm-common-node-types:node-types; description "Identifier for node-type e.g Roadm, xponder. For a given vendor and model, this leaf-list lists the node-types the manifest file is applicable to. "; } 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 openroadm-version { type org-openroadm-common-types:openroadm-version-type; description "This field should indicate the expected openroadm version 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 resync-after-commit-command { description "Support for a request to the controller to resync with the NE following a commit operation. This applies to the case where the commit is automatically executed by the NE, or if the commit is via the cancel-validation-timer operation. When using the cancel-validation-timer operation, this applies only when accept=true."; leaf resync-after-commit { type boolean; default "false"; description "Support for a request to the controller to resync with the NE following a commit operation. This applies to the case where the commit is automatically executed by the NE, or if the commit is via the cancel-validation-timer operation. When using the cancel-validation-timer operation, this applies only when accept=true."; } } 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 wait-time-command { description "Wait timer starting from the completion of sw-activate or db-activate before canceling the validation timer or rollback timer"; leaf wait-time { type uint16; mandatory true; description "See command for detailed description."; } } 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. validation-timer-start-ref: Qualifier for validation timer start applicability. Optional indication if the validation timer value will start before or after reboot. Only applicable if auto-reboot > 0. 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. timeout-start-ref: Qualifier for timeout start applicability. Optional indication if the timeout values will start before or after reboot. Only applicable if auto-reboot > 0. 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"; } leaf validation-timer-start-ref { type timer-ref-enum; } uses timeout-command; leaf timeout-start-ref { type timer-ref-enum; } uses command-reboot; leaf login-delay { type uint16; units "seconds"; description "The amount of time that the controller will delay before attempting to relogin to the device following the reboot after the sw-activate RPC. The timer begins upon receipt of the successful response to the sw-activate RPC. If not specified, there will be no additional delay and the controller will execute its normal connection retry mechanism."; } uses is-async-command; } } grouping cancel-validation-timer-command { description "cancel-validation-timer-command"; container cancel-validation-timer { when "../command = 'cancel-validation-timer'"; description "Command to automatically cancel the validation timer after wait-time. Accept will be set to True if this command is used. format: cancel-validation-timer wait-time [time-out] where: wait-time - wait timer starting from the completion of sw-activate before canceling the validation timer. timeout - see timeout-command grouping for basic details. Expected notifications: sw-activate-notification commit notification is expected. "; uses wait-time-command; uses timeout-command; uses is-async-command; uses resync-after-commit-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 cancel-rollback-timer-command { description "cancel-rollback-timer-command"; container cancel-rollback-timer { when "../command = 'cancel-rollback-timer'"; description "Command to automatically cancel the rollback timer after wait-time. Accept will be set to True if this command is used. format: cancel-rollback-timer wait-time [timeout] wait-time - Wait timer starting from the completion of db-activate before canceling the rollback timer. timeout - see timeout-command grouping for basic details. Expected notifications: db-activate-notification commit notification is expected. "; uses wait-time-command; 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. rollback-timer-start-ref: Qualifier for rollback timer start applicability. Optional indication if the rollback timer value will start before or after reboot. Only applicable if auto-reboot > 0. 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. timeout-start-ref: Qualifier for timeout start applicability. Optional indication if the timeout values will start before or after reboot. Only applicable if auto-reboot > 0. 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"; } leaf rollback-timer-start-ref { type timer-ref-enum; } uses timeout-command; leaf timeout-start-ref { type timer-ref-enum; } 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."; } leaf nsa-firmware-delay { type uint16; units "seconds"; description "The amount of time after the completion of an auto or manual commit operation for the device to finalize any non-service affecting firmware download. The controller will delay evaluating the circuit-pack-features/components list until after this timer has expired."; } uses resync-after-commit-command; 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 union { type identityref { base file-manifest-commands; } 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; uses cancel-validation-timer-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 union { type identityref { base file-manifest-commands; } 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 union { type identityref { base file-manifest-commands; } 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; uses cancel-rollback-timer-command; } } } container timeout-manifest { presence "The timeout-manifest provides information to the controller on the timeouts for retrieval and RPC commands that the controller supports."; description "The manifest file provides timeout values for certain retrieval and RPC operations supported by the controller. It also indicates if RPC operations are async or sync."; uses base-manifest { refine "sw-version" { mandatory true; } } list timeout-values { key "controller-vendor controller-model"; description "Set of timeout values indexed by the controller vendor and model. Since the retrieval and RPC operations may be supported differently by each controller, separate timeout-values and controller-defined command-names can be specified."; leaf controller-vendor { type string; description "Name of the vendor for the controller. This value should be provided by the controller."; } leaf controller-model { type string; description "Model of the controller. This value should be provided by the controller."; } list retrieval-command { key "command-name"; description "The list of retrieval commands supported by the controller."; leaf command-name { type string; description "Retrieval command name. The controller will support a specific set of retrival command-name strings. The controller will provide the list of command-names that are supported and how the command-name maps to a retrieval command."; } uses timeout-command; } list rpc-command { key "command-name"; description "The list of RPC commands supported by the controller."; leaf command-name { type string; description "RPC command name. The controller will support a specific set of RPC command-name strings. The controller will provide the list of command-names that are supported and how the command-name maps to a RPC command."; } uses timeout-command; uses is-async-command; } } } }