#228 Check LVM resize tests actually resized properly
Closed: Fixed a month ago by adamwill. Opened 3 months ago by adamwill.

I noticed yesterday that the install_resize_lvm test was "passing" without ever actually resizing anything. For it and blivet_resize_lvm we either need some more asserts in the partitioning phase, or a post-install test, to make sure they actually did what they were supposed to do.


Metadata Update from @lruzicka:
- Issue assigned to lruzicka

2 months ago

So, I have checked several cases of install_resize_lvm and on the first sight, they look ok. The root is resized from 14GiB to 13GiB and home is created in the remaining place.

Do you mean, that the test is passing when:

  • the partitions do not get resized in the background, even if the GUI shows it, or
  • that they do not get resized and the GUI shows they don't?
  • or is there a third option?

If you could point me to the test run where it happened, I would appreciate it truly.

Yeah, because I fixed it now :D You have to look back before I fixed it:
https://openqa.fedoraproject.org/tests/872322
if you click through the screenshots, you can see the test tries to resize a 9GiB partition to 13GiB, which doesn't work, and then tries to add another partition which also doesn't work as there's no space. But anaconda never outright fails - it just shows warnings, which the test ignores because the thing it's expecting to see is also there.

You could reproduce this for testing, BTW, without messing with createhdds again, by just increasing the size the test tries to resize to so it's again bigger than the existing partition. Set it to like 20GiB and the problem should come back - the test will pass when really we should catch it.

Note I would not want to 'fix' this by using a needle that looks for a warning message. The problem with "positive match fails" is that if e.g. the font changes, we will fail to see the warning and think everything's OK. As a general principle we should only use positive screenshot matches to check success, never to check failure. It would be better to use needles to check the size actually changed and the new partition was actually added, or a postinstall test that uses script assertions to check that everything is present and is the expected size.

Just to make sure we are on the same terms:

  • the testcase now uses an image produced by another installation test install_lvm_ext4 that created a 15GiB image
  • this image is now being used for the resize tests, which resize to 13 GiB and leave the 2 GiB for the home partition. This works well, but actually does not solve the situation because there still is a bug in the test.

I am suggesting the following fix:

  1. create a new assertion which checks that the size actually changes after we hit Update Settings (as seen here https://openqa.fedoraproject.org/tests/878888#step/disk_custom_resize_lvm/16). Because, with the failing variant, it did not change and we did not assert - this would fail the test immediately when the problem happens.
  2. add a post-install test that would check that partitions with the given size do exist.

Yup, that's basically right. The initial bug was "it wasn't resizing at all because the install_lvm_ext4 disk size was only 9GiB or something". I fixed that by changing it to 15GiB. But it could break again and we wouldn't easily know without carefully examining the test screenshots.

Yup, that resolution seems fine. either 1 or 2 would probably be enough, really, but doing both is safer if it's not too much work to implement or maintain.

Yikes, sort of slipped my mind. Sorry about that.

Login to comment on this ticket.

Metadata
Related Pull Requests
  • #237 Merged a month ago