[warm-reboot-version] warm reboot versioning document & design

[yxieca]

• Document the requirement of warm reboot versioning.
• Design solution for post warm reboot versioning.

Signed-off-by: Ying Xie ying.xie@microsoft.com

[jipanyang]

As to the "Provide post upgrading guidance for states restoration.", since we know the "from" version of sonic (or each specific docker), do we really need another specific version design? Could those version data be saved to the "warm-reboot-versions" file you proposed and used directly?

Except for few cases like lacp pdu data file for teamd, the application will restore data from database.
The possible data conversion from old version to new version, in common practice, usually should be done in some one time script before the application is started. Maybe in postStartAction() of database docker?

Each docker is supposed to certify the "From" version white list and provide the conversion scripts to be called there.

[jipanyang]

To add more clarification:
<1> We could save the "show version" data of "FROM" image, which includes the versions of the whole SONiC images and each specific docker, to /host/warmboot at the beginning of sonic_installer install processing.

<2> At preStartAction or postStartAction of database container, a script plugin mechanism should be designed.
So based on the specific container "FROM" version, a data schema transformation script should be provided by the "TO" version container if needed.

<3> The "TO" version of container/SONiC image is also responsible for maintaining the white list of supported "FROM" version. This one applies to both pre-upgrade and post-upgrade.

This doesn't conflict with Database container versioning, but gives finer control of software warm upgrade.