action #61997
closed
coordination #60071: [functional][y][epic] SLE 15 SP2 feature testing
[functional][y] Test snapper snapshot branch feature integration with transactional-update v.2.20 on SLE15
Added by oorlov over 4 years ago.
Updated over 4 years ago.
Description
Currently the version of transactional-update does not allow to test --continue feature on SLE15-SP2 (Build 122.1), as the version of transactional-update is 2.15, which does not have the changes. The ticket is created in order to test the feature as soon as the version will be 2.20.
See https://jira.suse.com/browse/SLE-7373 and https://jira.suse.com/browse/SLE-7333.
Please see the https://progress.opensuse.org/issues/60605 where manual testing on TW was performed.
Task¶
- Test
transactional-update --continue on SLE15-SP2 as soon as 2.20 version of transactional-update will be added to SLE;
- Consider different architectures (e.g. x86_64, s390x etc.)
- Description updated (diff)
- Due date set to 2020-02-11
We should get newer version in the next beta build.
- Status changed from New to Blocked
- Due date changed from 2020-02-11 to 2020-02-25
- Due date changed from 2020-02-25 to 2020-03-10
Still not in the build (139.4).
- Due date changed from 2020-03-10 to 2020-03-24
- Status changed from Blocked to Workable
- Assignee deleted (
riafarov)
- Priority changed from Normal to High
- Estimated time set to 5.00 h
- Assignee set to JERiveraMoya
- Status changed from Workable to In Progress
Regarding tools integration I found a couple of inconsistencies that I will comment in the feature:
After using snapper create --from,
- There is no Flags for read-write snapshot when checking with
btrfs subvolume show /.snapshots/<snap_num>/snapshot
- Deletion of intermediate snapshot still keep uuid which does not exist (but it could also happen when using rollback). Seen using
btrfs subvolume list / -qu
Regarding test scenarios for transactional-update I found interesting the ones as follows:
Test scenario 1:
transaction-update pkg in tree
transaction-update --continue pkg in unrar
transaction-update --continue pkg in zip
reboot
which tree unrar zip -> all three available
Test scenario 2:
transaction-update pkg in tree
transaction-update pkg in unrar
transaction-update --continue pkg in zip
reboot
which tree unrar zip -> all except tree available
Test scenario 3:
transaction-update pkg in tree
transaction-update --continue pkg in unrar // continue is optional here
transaction-update pkg in zip // last step is the only one applicable if last step does not have --continue
reboot
which tree unrar zip -> only zip available
Test scenario 4:
transaction-update pkg in tree // snapshot A
transaction-update pkg in unrar
transaction-update pkg --continue A in zip
reboot
which tree unrar zip -> tree and zip are available
Test scenario 5:
transaction-update pkg in tree
transaction-update pkg --continue pkg remove tree
reboot
which tree -> no available
Test scenario 6:
transaction-update pkg in tree // snapshot A
transaction-update pkg in unrar
transaction-update pkg --continue A in tree → nothing to update
Test scenario 7:
transaction-update pkg in tree // snapshot A
transaction-update pkg in unrar
transaction-update pkg --continue A remove tree
reboot
which tree unrar -> none available
I plan to do some additional testing in another arch.
- Status changed from In Progress to Resolved
Covered in zKVM 1-4, being 4 the most interesting for automation.
Also available in: Atom
PDF