-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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.
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
Run db_migrator for non first-time reboots #16116
Run db_migrator for non first-time reboots #16116
Conversation
Signed-off-by: Vivek Reddy Karri <vkarri@nvidia.com>
Signed-off-by: Vivek Reddy Karri <vkarri@nvidia.com>
Signed-off-by: Vivek Reddy Karri <vkarri@nvidia.com>
@@ -259,6 +259,16 @@ function postStartAction() | |||
# 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
if [ -e /tmp/pending_config_migration ] || [ -e ${CONFIG_SETUP_POST_MIGRATION_FLAG} ]; then |
and to
if [ -e /tmp/pending_config_initialization ] || [ -e ${CONFIG_SETUP_INITIALIZATION_FLAG} ]; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 <vkarri@nvidia.com>
@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 <vkarri@nvidia.com>
- 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 <vkarri@nvidia.com>
- 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 <vkarri@nvidia.com>
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 <vkarri@nvidia.com>
@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 <vkarri@nvidia.com>
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 <vkarri@nvidia.com>
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)