Cloud FW upgrade proposal #461
Conversation
|
Still reviewing. |
|
Minor: Please add a link to CloudIntegration.xml in index.html. It makes it more accessible to review on developer.onvif.org |
done in PR #462 |
There was a problem hiding this comment.
A first review of the core specification changes:
The acronyms MCS and OCS are not well known. Suggest to replace MCS everywhere by spelled out vendor cloud and OCS by spelled out operational cloud. Additionally explain both definitions in the terms and definitions section. Rationale for vendor vs manufacturer is that the term is shorter and not always the vendor is the manufacturer.
Are cloud firmware upgrade and StartCloudFirmwareUpgrade the right terms, as the mechanism is proprietary and might consist of simple pulling by the camera? For the function I would prefer something simpler like UpgradeFirmware.
doc/Core.xml
Outdated
| <para>The second is a two stage process; first the client sends the StartFirmwareUpgrade command to instruct the device to prepare for upgrade, then it sends the firmware image using HTTP POST.</para> | ||
| <para>The HTTP method is designed for resource-limited devices that may not be capable of receiving a new firmware image in its normal operating state.</para> | ||
| <para>The third method involves an interaction between OCS, MCS and the device, in order to | ||
| trigger the firmware upgrade.</para> |
There was a problem hiding this comment.
Great that you place it here, but it is very hard to understand. Please elaborate a bit more and avoid unfamiliar acronyms.
There was a problem hiding this comment.
Agreed. Here MCS and OCS should be expanded to their full meaning and also added as updates to the document "Definitions" with link / reference to the Cloud Integration Spec. If acronyms are needed then MCS & OCS should be added to the Abbreviations section.
There was a problem hiding this comment.
See my commit
| @@ -1270,9 +1286,13 @@ | |||
| </section> | |||
| <section> | |||
| <title>Firmware Upgrade</title> | |||
| <para>Two mechanisms are provided for upgrading the firmware on a device. The first uses the UpgradeSystemFirmware command to send the new firmware image using MTOM.</para> | |||
There was a problem hiding this comment.
Shouldn't we deprecate MTOM based firmware upgrade?
There was a problem hiding this comment.
@ocampana-videotec @HansBusch Agreed here as in Core Spec at 8.3.9 the API "UpgradeSystemFirmware" and 8.34 API "RestoreSystem" has been noted as "deprecated" for some time now. It is time to drop it.
There was a problem hiding this comment.
I have no objection for this. I propose we just share it during the next F2F meeting.
| @@ -1270,9 +1286,13 @@ | |||
| </section> | |||
| <section> | |||
| <title>Firmware Upgrade</title> | |||
| <para>Two mechanisms are provided for upgrading the firmware on a device. The first uses the UpgradeSystemFirmware command to send the new firmware image using MTOM.</para> | |||
There was a problem hiding this comment.
@ocampana-videotec @HansBusch Agreed here as in Core Spec at 8.3.9 the API "UpgradeSystemFirmware" and 8.34 API "RestoreSystem" has been noted as "deprecated" for some time now. It is time to drop it.
doc/CloudIntegration.xml
Outdated
| </mediaobject> | ||
| </figure> | ||
| <para>If the original connection to the MCS is kept, it is possibile for the MCS to perform FW | ||
| upgrade, upon request from the OCS. On the MCS, mutliple versions of FW images may be |
There was a problem hiding this comment.
| upgrade, upon request from the OCS. On the MCS, mutliple versions of FW images may be | |
| upgrade, upon request from the OCS. On the MCS, multiple versions of device FW images may be |
There was a problem hiding this comment.
should the sentence not read "On the MCS, multiple versions of device FW images shall be present for each model." ? as per your statement if a device may have multiple FW dependencies, then it would surely make sense to have the FW available.
Issue though how many FW Images per device should be supported by the MCS?
There was a problem hiding this comment.
I included you suggestion in my commit. I think that "multiple versions of device FW images shall be present" is a too strong requirement. I would prefer leaving vendors free to chose how many FW images they want to be available.
| </imageobject> | ||
| </mediaobject> | ||
| </figure> | ||
| <para>If the original connection to the MCS is kept, it is possibile for the MCS to perform FW |
There was a problem hiding this comment.
"If the original connection to the MCS is kept" there does not seem to be provision in the spec to maintain the MCS connection. Reading the Spec this connection is discarded once the device is assigned to an OCS. There is a note however that an OCS can be a PCS. More clarity needed here...
Should a device always maintain a connection to an MCS indefinitely for FW updates ?
There was a problem hiding this comment.
Once it is connected to an OCS, the device does not automatically closes the link to the MCS. It's up to the OCS to choose whether they want to delete the connection to the MCS or not.
doc/CloudIntegration.xml
Outdated
| <para>If the original connection to the MCS is kept, it is possibile for the MCS to perform FW | ||
| upgrade, upon request from the OCS. On the MCS, mutliple versions of FW images may be | ||
| present for each model, so that the OCS can select the desired one. In case upgrading to the | ||
| desired FW version will require multiple operations, the device and the MCS will performed |
There was a problem hiding this comment.
| desired FW version will require multiple operations, the device and the MCS will performed | |
| desired FW version will require multiple operations, the the MCS will manage the device upgrade |
There was a problem hiding this comment.
I changed from performed to perform. See if it sounds better.
| upgrade, upon request from the OCS. On the MCS, mutliple versions of FW images may be | ||
| present for each model, so that the OCS can select the desired one. In case upgrading to the | ||
| desired FW version will require multiple operations, the device and the MCS will performed | ||
| them automatically, without the need for the OCS to know the required steps.</para> |
There was a problem hiding this comment.
| them automatically, without the need for the OCS to know the required steps.</para> | |
| automatically, without the need for the OCS to know the required steps.</para> |
There was a problem hiding this comment.
same as in my previous comment
doc/Core.xml
Outdated
| <para>The second is a two stage process; first the client sends the StartFirmwareUpgrade command to instruct the device to prepare for upgrade, then it sends the firmware image using HTTP POST.</para> | ||
| <para>The HTTP method is designed for resource-limited devices that may not be capable of receiving a new firmware image in its normal operating state.</para> | ||
| <para>The third method involves an interaction between OCS, MCS and the device, in order to | ||
| trigger the firmware upgrade.</para> |
There was a problem hiding this comment.
Agreed. Here MCS and OCS should be expanded to their full meaning and also added as updates to the document "Definitions" with link / reference to the Cloud Integration Spec. If acronyms are needed then MCS & OCS should be added to the Abbreviations section.
Co-authored-by: Kieran McCartan <[email protected]>
@HansBusch I am open to any better name. We can discuss as we did for editable user levels vs. roles in the next F2F meeting |
This part of the spec has now its own branch and PR