Run db_migrator for non first-time reboots#16116
Run db_migrator for non first-time reboots#16116liat-grozovik merged 12 commits intosonic-net:masterfrom
Conversation
Signed-off-by: Vivek Reddy Karri <[email protected]>
Signed-off-by: Vivek Reddy Karri <[email protected]>
Signed-off-by: Vivek Reddy Karri <[email protected]>
| # This flag will be set to "1" after DB migration/initialization is completed as part of config-setup | ||
| $SONIC_DB_CLI CONFIG_DB SET "CONFIG_DB_INITIALIZED" "0" | ||
| else | ||
| if [[ "$BOOT_TYPE" != "warm" ]]; then |
There was a problem hiding this comment.
Why is this setting needed now, when it was not needed earlier? And, why is warm-reboot an exception?
There was a problem hiding this comment.
Because db_migrator busy waits when the CONFIG_DB_INITIALIZED flag is not set. Probably because of ConfigDBConnector https://github.com/sonic-net/sonic-swss-common/blob/master/common/configdb.cpp#L29.
I've only checked for warm-reboot since warm-reboot might already contain the CONFIG_DB_INITIALIZED from the previous db.
I feel its better to update db_migrator to not depend on CONFIG_DB_INIT, what do you think?
| $SONIC_DB_CLI CONFIG_DB SET "CONFIG_DB_INITIALIZED" "0" | ||
| fi | ||
| # this is not a first time boot to a new image. Datbase container starts w/ old pre-existing config | ||
| if [[ -x /usr/local/bin/db_migrator.py ]]; then |
There was a problem hiding this comment.
I am thinking if we not follow the same flow as we had earlier. Rather than that, why not confine all the migration logic in one place - config-setup.service?
This would ensure that migration also happens after the DB is loaded w/ relevant config - from minigraph, old config, new pushed config, etc.
Specifically, I am asking that this db_migrator call be moved here as part of new else block:
and to
There was a problem hiding this comment.
We have to run it here since the config_db.json has to be loaded first. If we move this to config-setup, this can't be guaranteed.
…to db_mig_succesive_boot
Signed-off-by: Vivek Reddy Karri <[email protected]>
|
@vaibhavhd Handled the comments. the db_migrator fix is actually not required given we are setting the INIT flag to 0 in db. service. I will fix the db_migrator script later but since that is not required here i don't want to tie that optional fix with this PR. |
|
/azpw run Azure.sonic-buildimage |
|
/AzurePipelines run Azure.sonic-buildimage |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Failing in kvmtest-multi-asic-t1-lag. i.e. on masic platforms. Will move the migration back to database.service. |
Signed-off-by: Vivek Reddy Karri <[email protected]>
- Why I did it The recent change #15685 (comment) removed the db migration for non first reboots. This is problematic for many deployments which doesn't rely on ZTP and push a custom config_db.json Port to older branches after #15685 is ported back - How I did it Re-introduce the logic to run the db_migrator on non-first boots - How to verify it Verified reboot and warm-reboot cases Signed-off-by: Vivek Reddy Karri <[email protected]>
- Why I did it The recent change sonic-net#15685 (comment) removed the db migration for non first reboots. This is problematic for many deployments which doesn't rely on ZTP and push a custom config_db.json Port to older branches after sonic-net#15685 is ported back - How I did it Re-introduce the logic to run the db_migrator on non-first boots - How to verify it Verified reboot and warm-reboot cases Signed-off-by: Vivek Reddy Karri <[email protected]>
|
Cherry-pick PR to 202012: #16477 |
- Why I did it The recent change #15685 (comment) removed the db migration for non first reboots. This is problematic for many deployments which doesn't rely on ZTP and push a custom config_db.json Port to older branches after #15685 is ported back - How I did it Re-introduce the logic to run the db_migrator on non-first boots - How to verify it Verified reboot and warm-reboot cases Signed-off-by: Vivek Reddy Karri <[email protected]>
|
@yxieca Can you please help with the cherry-pick to 202205? |
- Why I did it The recent change sonic-net#15685 (comment) removed the db migration for non first reboots. This is problematic for many deployments which doesn't rely on ZTP and push a custom config_db.json Port to older branches after sonic-net#15685 is ported back - How I did it Re-introduce the logic to run the db_migrator on non-first boots - How to verify it Verified reboot and warm-reboot cases Signed-off-by: Vivek Reddy Karri <[email protected]>
|
Cherry-pick PR to 202205: #16520 |
- Why I did it The recent change sonic-net#15685 (comment) removed the db migration for non first reboots. This is problematic for many deployments which doesn't rely on ZTP and push a custom config_db.json Port to older branches after sonic-net#15685 is ported back - How I did it Re-introduce the logic to run the db_migrator on non-first boots - How to verify it Verified reboot and warm-reboot cases Signed-off-by: Vivek Reddy Karri <[email protected]>
Why I did it
The recent change #15685 (comment) removed the db migration for non first reboots.
This is problematic for many deployments which doesn't rely on ZTP and push a custom config_db.json
Port to older branches after #15685 is ported back
Work item tracking
How I did it
Re-introduce the logic to run the db_migrator on non-first boots
How to verify it
Verified reboot and warm-reboot cases
Which release branch to backport (provide reason below if selected)
Tested branch (Please provide the tested image version)
Description for the changelog
Link to config_db schema for YANG module changes
A picture of a cute animal (not mandatory but encouraged)