--- /dev/null
+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;
+ }
+ }
+ }
+}
Code Review / transportpce.git / blobdiff