@sujinmkang IMHO, this should be fetched automatically by Platform API if needed.
The config file should be simple and clear.

Use case: the same firmware package may have a different behaviour based on device vendor/model.
Example: SSD with/without on-the-fly update mode

@sujinmkang Typo? Maybe it's better to have something like platform_fw_updates?

@sujinmkang Not sure whether this is the right place for fw binaries. Also this may overlap with the sonic_device_data package contents.

@sujinmkang What about modular platforms? AFAIK, there is no clear restrictions on component names, which means that different modules can share the same component name. And what should be the expected behaviour in that case?

@sujinmkang I suggest to use something like:
fwutil update components fw --yes --image=next --boot=fast

@sujinmkang I would like to propose a new CLI tree:

fwutil
|--- show
|    |--- version
|    |--- status
|    |--- updates -i|--image=<current|next> -c|--config=<path_to_platform_fw_updates>
|
|--- install
|    |--- chassis
|    |    |--- component <component_name>
|    |         |--- fw -y|--yes <fw_path>
|    |
|    |--- module <module_name>
|         |--- component <component_name>
|              |--- fw -y|--yes <fw_path>
|
|--- update
     |--- chassis
     |    |--- component <component_name>
     |         |--- fw -y|--yes -f|--force -i|--image=<current|next> -c|--config=<path_to_platform_fw_updates>
     |
     |--- module <module_name>
     |    |--- component <component_name>
     |         |--- fw -y|--yes -f|--force -i|--image=<current|next> -c|--config=<path_to_platform_fw_updates>
     |
     |--- components
          |--- fw -y|--yes -f|--force -i|--image=<current|next> -b|--boot=<cold|fast|warm> -c|--config=<path_to_platform_fw_updates>

@sujinmkang Some thoughts:

1. In case platform API is not implemented (plugin mode) the fwutil CLI won't be fully available - only automatic installation mode. That's something which need to be highlighted in this design
2. Platform API should be extended with the new boot argument
3. How to handle version and script fields in case Platform API is not implemented
4. Need to extend the design with some output examples for automatic installation mode

Hi Sujin,

In what scenarios the fwutil command will include a reboot/powercycle? only in cases of immediate_(fast/warm/cold/powercycle)?

Also in few cases the upgrade may require unmount of filesystems and better to include them in the flow of reboot after unmounting filesystems. In that case fwutil can do just the placing of files in correct location and the actual upgrade will be done only as part of the reboot script. In those scenarios if this command just places the file, in what ways the actual upgrade can be included in these scripts?

Do you know the answer about your first question? I also have this question.
####In what scenarios the fwutil command will include a reboot/powercycle? only in cases of immediate_(fast/warm/cold/powercycle)?####

boot option needs to be added

So, in the CPLD example above, the fwutil auto-update will be functionally equivalent to the existing "fwutil install" command, please mention this in the description.

typo

The "fwutil show auto-update" command has status as "updated but need a power-cycle". Please explain how these status will be derived from these utility return strings described above.

@sujinmkang How do you expect to handle power cycle scenario? SONiC can only distinguish between cold/fast/warm reboots in scope of firmware upgrade framework.

that is good question. I think we should limit this boot option to non/fast/warm/cold.

@sujinmkang Looks good. Please update the design

@sujinmkang what is the expected behaviour when --image=next and --fw-image=<fw_package.tar.gz> are provided simultaneously?

We should take only one option. my current implementation takes the --fw-image option over --image option. Should we return error when user gives both option for one fwutil call?

@sujinmkang please elaborate a bit more for a different flows (cold/warm/fast): at which point do you expect to call this plugin?

@sujinmkang in case of boot_action=any what should be the expected behaviour if platform component supports both cold and fast reboot? Do we expect platform API will add this item to both cold_* and fast_* task lists?

As I replied in your previous question, we need to limit the boot action by none/fast/warm/cold. And in the previous comments, we don't support multiple firmware auto update for the same or other boot type.

@sujinmkang how do we expect to use this info in FW tools when we don't have a way to read the original (before the update) firmware version?

This api should retrieve the original version from the platform device. not the update firmware version.

@sujinmkang why not to use a set of separate options: e.g. --fw and --boot

this utility will replace the platform api so I was expecting to pass the firmware path and boot type without any separate option. I will clarify this part.

@sujinmkang From the code changes, the utility -a interface alone has been used. So is it required for the utility to have the other interfaces implemented?

@sujinmkang is it ok for you that firmware update may not happen if there is no platform components which support this boot action?

Yes. if there is no platform component firmware update available for the boot action, no firmware update is expected. The fwutil will return a message saying "no update is available for the specific boot type"

@sujinmkang What if the cold/fast/warm boot was specified as the desired action but some of the platform components do support firmware upgrade without dataplane interruption? Do we expect the update will take place implicitly or we still do want to do only with --boot=none?

That is good question. Without boot option, the update which can be done without data plane interruption, should be performed implicitly. I will add the default setting for boot type.

@sujinmkang Looks good. Please update the design

@sujinmkang We need a way to inform user about what components do support automatic firmware upgrade (e.g, if i do auto-update, the framework will definitely try to upgrade firmware of that components). Without this the behaviour will be non deterministic, since the decision will be taken at field by platform API/plugin. Taken this into consideration, i would expect to see some Auto Update column here with values Yes/No

@nazariig All components need to support the automatic firmware update but only any component firmware update won't happen during this boot time if the auto-update cannot be done for the boot type. And user will notify the components firmware update cannot be done for the boot-type. I don't think it's necessary.

@sujinmkang please fix a typo firmware update

@sujinmkang please update the design with status codes

@nazariig This is how fwutil save the status of auto-update in the fw_au_status file. I'm proposing that fwutil needs to process the return code of platform component api and save the process data as this format.

@sujinmkang can we have a schema of this custom firmware package and some examples in design document?

@sujinmkang IMHO, the original idea of FW package was to provide an ability to do the upgrades on platforms which don't support platform API. Do we really want to use it for upgrades which involves platform API, when fwutil is already provides an infrastructure for that (e.g, this can be achived with FW deb packages)?

@nazariig I think it's good point. I understand we use the FW deb package to installed firmware which is missing from the current package. We can support both for the new firmware update based on the current image. But when we use a deb package to perform auto-update, we need 3 steps, push the firmware deb package, install the deb package and fwutil auto-update while this FW package approach needs 2 steps for auto update, push the FW package and fwutil aut-update with the FW package.

@sujinmkang Please update CLI tree to use new update all format

@sujinmkang we need to refactor this part too since moving from auto-update to update all

I think this can be changed to update_status but I hope this doesn't mislead people to think that they could check the each component update done by fwutil update {chassis|module <module_name>} component <component_name> fw ....
But I agree to change the command.