Project

General

Profile

Actions

action #46562

closed

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

Added by riafarov almost 6 years ago. Updated 10 months ago.

Status:
Rejected
Priority:
Low
Assignee:
-
Target version:
QA (public, currently private due to #173521) - future
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
Actions #1

Updated by okurz almost 6 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?

Actions #2

Updated by okurz almost 6 years ago

  • Target version changed from Milestone 23 to Milestone 25

@riafarov ping on the above

Actions #3

Updated by okurz over 5 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" :)

Actions #4

Updated by riafarov about 4 years ago

  • Project changed from openQA Tests (public) to qe-yam
  • Category deleted (New test)
Actions #5

Updated by JERiveraMoya 10 months ago

  • Status changed from New to Rejected

Backlog clean-up.

Actions

Also available in: Atom PDF