Project

General

Profile

action #46562

[functional][y][snapper] Test regression bsc#1111414 for snapper comparison

Added by riafarov over 2 years ago. Updated 9 months ago.

Status:
New
Priority:
Low
Assignee:
-
Target version:
Start date:
2019-01-23
Due date:
% Done:

0%

Estimated time:

Description

Motivation

We had a regression that snapper comparison algorithm fallbacks to the slow and dumb comparison when it should not, which appears as a severe performance degradation.
There are certain exceptions where this behavior is acceptable, but that's rare occasion.
We were asked to introduce automated test for that.

To validate that bug is not there, it's enough to perform following steps:

  1. Create snapshot
  2. Compare directory/file with snapshot
  3. Validate the /var/log/snapper.log file, which should not contain following lines: "cmpDirs fallback", "special btrfs cmpDirs failed, btrfs send/receive error" 2019-01-23 14:29:20 MIL libsnapper(4646) Btrfs.cc(process):1359 - dir1:'//.snapshots/5/snapshot' dir2:'//.snapshots/6/snapshot' 2019-01-23 14:29:20 ERR libsnapper(4646) Btrfs.cc(dumper):1253 - btrfs_read_and_process_send_stream failed 2019-01-23 14:29:20 WAR libsnapper(4646) Btrfs.cc(do_send):1315 - THROW: btrfs send/receive error 2019-01-23 14:29:20 ERR libsnapper(4646) Btrfs.cc(cmpDirs):1404 - special btrfs cmpDirs failed, btrfs send/receive error 2019-01-23 14:29:20 MIL libsnapper(4646) Btrfs.cc(cmpDirs):1405 - cmpDirs fallback

Comparison can be done issuing command: snapper diff number1..number2 [files],
where number1 and number2 are snapshot numbers.

Acceptance criteria

  1. There is test module which assures that snapper comparison mechanism doesn't fallback to generic mechanism

History

#1 Updated by okurz over 2 years ago

riafarov wrote:

We were asked to introduce automated test for that.

I am interested. How exactly did that happen? I also followed the bug and the according trello card and comments.

I wonder, this looks like a good use case for a YaST developer to get accustomed to openQA as the instructions as suggested above should be easy to provide. With the option to trigger tests on arbitrary git repos and branches one can even write the changes "blindly" and we trigger tests on production based on the PR's branch. WDYT?

#2 Updated by okurz over 2 years ago

  • Target version changed from Milestone 23 to Milestone 25

riafarov ping on the above

#3 Updated by okurz over 2 years ago

  • Priority changed from Normal to Low
  • Target version changed from Milestone 25 to future

let's focus more on improving our current tests and workflows first. Putting to "holding tank" :)

#4 Updated by riafarov 9 months ago

  • Project changed from openQA Tests to qe-yast
  • Category deleted (New test)

Also available in: Atom PDF