Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[component] add auto_update_firmware() to support the auto update. #106

Merged
merged 8 commits into from
Jan 26, 2021
Merged

[component] add auto_update_firmware() to support the auto update. #106

Changes from 6 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
f26b932
add boot_action option to fwutil update command
sujinmkang Aug 4, 2020
c03fb4e
add auto_update_firmware api to support
sujinmkang Sep 10, 2020
c8fce83
remove command argument
sujinmkang Oct 6, 2020
b6b0f41
add more clarification on return of auto_update_firmware api
sujinmkang Oct 29, 2020
3a88347
add more information on auto_update input and return values
sujinmkang Nov 20, 2020
1d56deb
review comments
sujinmkang Nov 24, 2020
4c86ecc
review comments
sujinmkang Nov 30, 2020
87cd0ee
address review comments
sujinmkang Jan 14, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 32 additions & 0 deletions sonic_platform_base/component_base.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -103,3 +103,35 @@ def update_firmware(self, image_path):
RuntimeError: update failed
"""
raise NotImplementedError

def auto_update_firmware(self, image_path, boot_action):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sujinmkang since this API is a part of SONiC firmware upgrade framework, please provide the description on which boot types are supported

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sujinmkang suggest renaming: boot_action -> boot_type

"""
Updates firmware of the component

This API performs firmware update automatically based on boot_action: it assumes firmware installation
and/or creating a loading task during a boot action, if needed, in a single call.
In case platform component requires some extra steps (apart from calling Low Level Utility)
to load the installed firmware (e.g, reboot, power cycle, etc.) - this will be done automatically during the reboot.
The loading task will be created by API.

Args:
image_path: A string, path to firmware image
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image_path : can it be mentioned that the firmware_image be a self extracting binary..

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got clarification from HLD.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This API will have any return values? Please mention if required.

boot_action: A string, boot action following the upgrade
- none/fast/warm/cold

Returns:
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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

- status_updated = 2
- status_scheduled = 3
- return_code of a negative number indicates failed auto-update
- status_err_boot_type = -1
- status_err_image = -2
- status_err_others = -3
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sujinmkang maybe it's better to use err_unknown?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nazariig please review this PR again.


Raises:
RuntimeError: auto-update failure cause
"""
raise NotImplementedError