-
Notifications
You must be signed in to change notification settings - Fork 18
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
Backup and restore /etc/products.d (bsc#1219004) #229
Conversation
During a migration I see that the templated repos.sh restore script has been updated to include the etc/products.d:
Similarly the restore tarball includes the etc/products.d files:
|
Can you please provide a test case how to test this change? Should be easy I assume but we have our internal ruling to try to provide at least one test case per pull request :) |
Do you mean a feature test or a unit test? There don't appear to be existing unit or feature tests for backup or restore, though I may not be grokking things in the Ruby testing stuff properly... |
The Distribution Migration System (DMS) implements a non-interactive fully automated offline migration of systems by booting into a ISO image that runs through the migration. In some cases, if a migration from one product stream to another product stream fails, the normal rollback handling doesn't always restore the products state correctly. To address this we should include the /etc/products.d contents in the backup that is created and restored. Add changelog entry for upcoming v1.9.0 release stream, including the bug tracking id. Add unit test for the zypper Backup and Restore routines. Also fix two bugs found while developing the unit test: * CreateTarball()'s check for potential tar arguments incorrectly checked under the local file system hierarchy, rather than under the specified root hierarchy, meaning it could skip backing up entries that might exist under the root if they didn't exist locally. * The /var/adm/backup/system-upgrade directory created under the specified root hierarchy, and missing intermediary directories, were being created with no access permissions, meaning that only a privileged superuser could access them. In reality migrations are run as root so it didn't impact customer usage, but it did cause problems for the unit tests running as a non-privileged user. Fixes: #231, #232 Co-authored-by: Felix Schnizlein <[email protected]>
274204b
to
a75c944
Compare
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.
lgtm 👍
How I reviewed this pull request:
- Ran a migration from
15.3
to15.5
and checked that both:/var/adm/backup/system-upgrade/repos.sh
/var/adm/backup/system-upgrade/repos.tar.gz
exist
- Checked that repos.sh includes
products.d
directory - Checked that repos.tar.gz includes
products.d/
directory content - Let the migration rollback and check that everything as been reset
As always, if you think I missed something I should test, please let me know!🚀
The Distribution Migration System (DMS) implements a non-interactive
fully automated offline migration of systems by booting into a ISO
image that runs through the migration. In some cases, if a migration
from one product stream to another product stream fails, the normal
rollback handling doesn't always restore the products state correctly.
To address this we should include the /etc/products.d contents in the
backup that is created and restored.
Add changelog entry for upcoming v1.9.0 release stream, including the
bug tracking id.
Add unit test for the zypper Backup and Restore routines.
Also fixed two bugs found while developing the unit test:
CreateTarball()'s check for potential tar arguments incorrectly
checked under the local file system hierarchy, rather than under
the specified root hierarchy, meaning it could skip backing up
entries that might exist under the root if they didn't exist
locally.
The /var/adm/backup/system-upgrade directory created under the
specified root hierarchy, and missing intermediary directories,
were being created with no access permissions, meaning that only
a privileged superuser could access them. In reality migrations
are run as root so it didn't impact customer usage, but it did
cause problems for the unit tests running as a non-privileged
user.
Fixes: #231, #232
Co-authored-by: Felix Schnizlein [email protected]