search

OpenROADM / OpenROADM_MSA_Public

Open ROADM MSA
http://www.openroadm.org/
61 stars 77 forks source link

Question for manifest file #34

Closed Infinera-OR closed 5 years ago

Infinera-OR commented 5 years ago

The manifest file designed for list the detail available operation for DB/SW. Then:

  1. The manifest model defined in the common model so that whether current running SW's manifest file data need be reported on this model and open for operator to modify? Because the manifest shall be the specific for the device operating manual it shall not be opened to modifying, so that not very clear the scenario. Or the model is just used for buildup the manifest file?

  2. If the SW load upload to device with this version's manifest file, will the system report the new version's manifest information in the model? Generally there were two parts steps to complete the upgrading: steps in current SW and the operation after system loading the new version SW. The steps after new version SW loading will be included in the new version manifest . So that before the SW switching(rebooting) the operator don't know the operating request.

fgruman commented 5 years ago

At this time, the manifest file would be provided by the vendor to the controller out-of-band and not be reported directly from the device. This is because at the time of release A, the instructions for defining how to upgrade to release B may not have been finalized. E.g., the list of files that may need to be transferred may not be known.

We did document this behavior in the Device Model white paper available on openroadm.org:

Software manifest YANG module. Note that this is not intended to be implemented on the device but provides the format of data that would be provided out-of-band to a controller to guide the controller on software download and database operations.

The model is just used to document formally the format of the manifest file.

A single manifest file would contain the steps that would be needed to upgrade the current software release to the next release. It includes both the parts before the upgrade as well as after the upgrade. Before the upgrade includes: transfer files, stage files and activate the new release. After the system comes up in the new release, there may be a validation period. The final step would be to cancel the validation time and accept the new load. This isn't explicitly provided in the manifest file as it was thought this operation would be manually triggered (not desired to be automatic, as we want someone to validate the network operations before accepting the load).

Infinera-OR commented 5 years ago

Thanks the feedback.