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.

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

SONiC configuration setup enhancements to provide installer migration… #590

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

rajendra-dendukuri
Copy link
Contributor

… hooks capability

The following new features are being added to the config-setup service:

  1. Provide a second set of configuration pre hooks as part of the installer
    image. This allows the user to fix issues caused by the migration-pre
    scripts already installed on the switch.

  2. Both the config-migration-pre and config-migration-post are migrated to
    the newly installed image. This allows end user installed scripts to be
    carried over to the newly installed image automatically to make it easier
    for subsequent configuration migrations.

Signed-off-by: Rajendra Dendukuri rajendra.dendukuri@broadcom.com

… hooks capability

The following new features are being added to the config-setup service:
1. Provide a second set of configuration pre hooks as part of the installer
image. This allows the user to fix issues caused by the migration-pre
scripts already installed on the switch.

2. Both the config-migration-pre and config-migration-post are migrated to
the newly installed image. This allows end user installed scripts to be
carried over to the newly installed image automatically to make it easier
for subsequent configuration migrations.

Signed-off-by: Rajendra Dendukuri <rajendra.dendukuri@broadcom.com>
The user can use the *sonic_installer* utility to install a new version of SONiC firmware. As part of this procedure, sonic_installer takes a backup of all files in directory */etc/sonic* and copies them as */host/old_config*. Later when switch boots into the newly installed image, a file */tmp/pending_config_migration* is created by rc.local service and config-setup service makes note of it. The backed up files in /host/old_config are then restored to /etc/sonic directory and the restored startup-config file is loaded to Config DB.
The user can use the *sonic_installer* utility to install a new version of SONiC firmware. As part of this procedure, sonic_installer takes a backup of all files in the directory */etc/sonic* and copies them as */host/old_config*. The *config-migration-pre-hooks* and the *config-migration-post-hooks.d* which are described in the subsequent sections are also backed up as part of this action.

Later when the switch boots into the newly installed image, a file */tmp/pending_config_migration* is created by rc.local service and config-setup service detects its presence and starts the configuration migration action. The backed up files in /host/old_config are then restored to /etc/sonic directory and the restored startup-config file is loaded to Config DB. The *config-migration-pre-hooks* and the *config-migration-post-hooks.d* are also restored to the newly installed image from their backed up copies. If the new image contains files in the migration hooks directories with the same filename as the backed up files, they are not overwritten and instead the files in the newly installed image will be used for configuration migration. This allows the newer version images to provide updated migration logic and deprecate the older (possibly incorrect) implementations.
Copy link
Collaborator

Choose a reason for hiding this comment

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

If my understanding is correct, in current implementation the startup_config migration is performed by the '/usr/bin/db_migrator.py' script, what's the plan for this part of function? will the db_migrator.py be kept or have something new to replace it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The /usr/bin/db_migrator.py is responsible to migrate the contents of the startup_config. The config-setup.service, which calls /usr/bin/config-setup is responsible to migrate the startup_config file. The config-setup service calls db_migrator.py. They both work together.

@yxieca yxieca force-pushed the master branch 2 times, most recently from 8498931 to 8837dc2 Compare April 15, 2022 16:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants