[component] add auto_update_firmware() to support the auto update.#106
[component] add auto_update_firmware() to support the auto update.#106sujinmkang merged 8 commits intosonic-net:masterfrom
Conversation
|
@padmanarayana can you review this? |
| The loading task will be created by API. | ||
|
|
||
| Args: | ||
| image_path: A string, path to firmware image |
There was a problem hiding this comment.
image_path : can it be mentioned that the firmware_image be a self extracting binary..
| The loading task will be created by API. | ||
|
|
||
| Args: | ||
| image_path: A string, path to firmware image |
There was a problem hiding this comment.
This API will have any return values? Please mention if required.
|
|
||
| Returns: | ||
| Output: A string, status and info | ||
| status: True or False, firmware auto-update status |
There was a problem hiding this comment.
@sujinmkang suggest to use status codes:
status_installed=1
status_updated=2
status_scheduled=3
There was a problem hiding this comment.
@nazariig
the original idea was for status to indicate the auto-update performed status which means performed successfully or not. For info, it gives more detail how the update has been performed. And platform vendor can return any information for the failure that is why the info was open.
Instead of having two outputs for the api, we can define the return_code as below based on your input . do you have any other failure cause to be added?
return_code
status_installed = 1
stauts_updated = 2
status_scheduled = 3
status_error_boottype = -1
status_error_image = -2
status_error_others = -3
| """ | ||
| raise NotImplementedError | ||
|
|
||
| def auto_update_firmware(self, image_path, boot_action): |
There was a problem hiding this comment.
@sujinmkang since this API is a part of SONiC firmware upgrade framework, please provide the description on which boot types are supported
|
@nazariig can I submit this PR if you don't have any other comment? |
| Output: A return code | ||
| return_code: An integer number, status of component firmware auto-update | ||
| - return code of a positive number indicates successful auto-update | ||
| - status_installed = 1 |
There was a problem hiding this comment.
@sujinmkang IMHO, status installed is not relevant for this flow, since it requires some additional steps from user (e.g., power cycle for CPLD/FPGA, etc.), thus such an operation can't be claimed as automatic firmware upgrade.
There was a problem hiding this comment.
@nazariig This has been discussed several time. auto-update is expected to be able to perform install/ update/ creating a task for the components firmware update if the update is available for the boot_type.
The decision should be done by the platform api.
For example, with cold boot, cpld firmware update can be done if the reboot plugin can handle the powercycle flag to complete the cpld firmware update. For warm/fast reboot, the cpld firmware update won't happen and the platform api will return boot_type error? fwutil will not exit for the boot_type error since the firmware auto-update is not just supported in that boot_type case.
There was a problem hiding this comment.
For warm/fast reboot, the cpld firmware update won't happen and the platform api will return boot_type error? fwutil will not exit for the boot_type error since the firmware auto-update is not just supported in that boot_type case.
@sujinmkang that is clear, but i am talking about the case when we have status_installed.
What is the use case for this status code? Basically this means that user still needs to do some manual steps to finish firmware upgrade and this is something completely different to what we call automatic.
| """ | ||
| raise NotImplementedError | ||
|
|
||
| def auto_update_firmware(self, image_path, boot_action): |
There was a problem hiding this comment.
@sujinmkang suggest renaming: boot_action -> boot_type
| - return_code of a negative number indicates failed auto-update | ||
| - status_err_boot_type = -1 | ||
| - status_err_image = -2 | ||
| - status_err_others = -3 |
There was a problem hiding this comment.
@sujinmkang maybe it's better to use err_unknown?
…ies in setup.py (sonic-net#106) Remove dependence on the 'enum' package, as we are currently transitioning from Python 2 to Python 3 and there are installation conflict issues between the `enum` package and the `enum34` package. Add 'sonic-py-common' as dependencies in setup.py for xcvrd, also add spaces around "equals" signs.
To support the component firmware automatic update, add auto_update_firmware() to platform component api
This is to support fwutil auto_update command to update the platform component firmware automatically.
Fwutil HLD to support auto_update interfaces/commands.
sonic-net/SONiC#648