Project

General

Profile

Actions

action #40682

closed

coordination #40469: [functional][y][epic] Adjust RAID/LVM/partitioning tests to the new changes and extend testing coverage

[functional][y] full disk as LVM PV

Added by ancorgs over 5 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
New test
Target version:
SUSE QA - Milestone 25
Start date:
2018-09-06
Due date:
2019-06-18
% Done:

0%

Estimated time:
8.00 h
Difficulty:

Description

In the partitioner is possible to create an LVM VG on top of partitions and disks (without partition table) alike. I'm not sure if we have a test-case using that functionality or if all our tests define the LVM always based on partitions.

If we don't have it, it would be nice to add it.

Automation is out of scope of the ticket, we should create follow up ticket, we have AY test on 64 bit already, as of now this is already good. But we should come up with some scenario which would be beneficial to automate.

Acceptance criteria

  1. Functionality is tested manually using TW, Leap 15.1, SLE 15 SP1 which contain changes
  2. Draft test plan for the feature is created
  3. Follow up ticket for the automated test is created depending on the outcome of the test plan

Suggestions

Things to test and not limited to:

  1. Partitionless physical volume with btrfs
  2. Partitionless physical volume with ext4
  3. volume group on multiple partitons
  4. volume group on multiple disks
  5. 1-4 with encrypted lvm (for VG)
  6. 1-4 with encrypted lvm and encrypted partitions in VG
  7. VG with a disk and lvm partition
  8. Activation of the disk partitions by installer when having a disk with installations from 1-7
  9. At least perform one autoyast re-installation (install -> clone system -> install using created profile), use testing strategies here not to repeat this step for 1-8
  10. Whole disk as a single partition
  11. Special disks (DASD, ZFCP, iSCSI)
  12. Repeat some of the suggestions using Expert Partitioner in the installed system

AY scenario is already automated: https://openqa.suse.de/tests/latest?arch=x86_64&version=15-SP1&machine=64bit&test=autoyast_disk_as_pv&distri=sle&flavor=Installer-DVD
But it's only 64bit, worth checking on other setups.


Related issues 2 (0 open2 closed)

Related to openQA Tests - action #42605: [functional][y][autoyast][storage-ng] Test disk directly as PVResolvedriafarov2018-10-172018-12-04

Actions
Copied to qe-yam - action #53243: [functional][y] Automate scenario for full disk as LVM PVRejected2018-09-06

Actions
Actions #1

Updated by okurz over 5 years ago

I think so far we covered this manually to confirm it did not work in older versions :)

#32035 is the related ticket for manual testing on the feature https://fate.suse.com/324990

Actions #2

Updated by okurz over 5 years ago

  • Subject changed from Ensure we have a test with a full disk as LVM PV to [functional][y] full disk as LVM PV
  • Category set to New test
  • Target version set to Milestone 22
Actions #3

Updated by riafarov over 5 years ago

  • Description updated (diff)
  • Due date set to 2018-10-09
  • Status changed from New to Workable
Actions #4

Updated by okurz over 5 years ago

  • Due date deleted (2018-10-09)

Hi riafarov, I have planned this for M22 and I would prefer to not have more "New Test" that soon. Happened again just today that we "overlooked" our best practices regarding introduction of new tests and annoyed @dimstar, see discussion in #opensuse-factory. Hence I want to be a bit more careful and conservative, so not planned for S27, ok?

Actions #5

Updated by okurz over 5 years ago

  • Related to action #42605: [functional][y][autoyast][storage-ng] Test disk directly as PV added
Actions #6

Updated by riafarov over 5 years ago

  • Related to deleted (action #42605: [functional][y][autoyast][storage-ng] Test disk directly as PV)
Actions #7

Updated by mloviska over 5 years ago

  • Due date set to 2018-11-06
Actions #8

Updated by riafarov over 5 years ago

  • Description updated (diff)
Actions #9

Updated by riafarov over 5 years ago

  • Description updated (diff)
  • Estimated time set to 13.00 h
Actions #10

Updated by okurz over 5 years ago

  • Status changed from Workable to Blocked
  • Assignee set to riafarov

from #yast:

[25/10/2018 09:41:13] <okurz> ancor: Because you create a ticket for test extending, "full disk as LVM PV", is this already in openSUSE:Factory or missing a SR?
[25/10/2018 09:51:53] <imobach> okurz: http://build.opensuse.org/request/show/643889
[25/10/2018 09:52:19] <imobach> okurz: that SR contains the latest changes in storage-ng + AutoYaST

meaning to me that we should look into the corresponding staging test in staging project :H . but first we need to bring the RAID changes into TW for these tests to pass -> #42908

Putting ticket as Blocked on riafarov as he works on #42908

Actions #11

Updated by riafarov over 5 years ago

  • Due date changed from 2018-11-06 to 2018-12-04
Actions #12

Updated by riafarov over 5 years ago

  • Status changed from Blocked to Workable
  • Assignee deleted (riafarov)

Unblocked, changes in TW, where we can start with new test.

Actions #13

Updated by riafarov over 5 years ago

  • Description updated (diff)
Actions #14

Updated by okurz over 5 years ago

  • Due date changed from 2018-12-04 to 2019-01-29
  • Status changed from Workable to Blocked
  • Assignee set to okurz

let's do the corresponding autoyast part in #42605 first, shall we?

Actions #15

Updated by riafarov about 5 years ago

  • Status changed from Blocked to Workable
  • Assignee deleted (okurz)

#42605 resolved

Actions #16

Updated by riafarov about 5 years ago

  • Due date changed from 2019-01-29 to 2019-02-12
Actions #17

Updated by okurz about 5 years ago

  • Related to action #42605: [functional][y][autoyast][storage-ng] Test disk directly as PV added
Actions #18

Updated by okurz about 5 years ago

  • Due date deleted (2019-02-12)
  • Priority changed from Normal to Low
  • Target version changed from Milestone 22 to Milestone 24

@riafarov Not sure why you deleted the relation to #42605 . This one is for the functionality to be covered in general and #42605 is about autoyast so I see a strong relation.

As we have the autoyast test and therefore some parts covered I regard this one with "low" prio and recommend to postpone it to a later milestone. Agreed to do plan it for M24?

Actions #19

Updated by okurz about 5 years ago

  • Due date set to 2019-06-04
Actions #20

Updated by riafarov almost 5 years ago

  • Description updated (diff)
  • Estimated time deleted (13.00 h)

Scope of the ticket was changed, so removed estimate.

Actions #21

Updated by riafarov almost 5 years ago

  • Target version changed from Milestone 24 to Milestone 25
Actions #22

Updated by riafarov almost 5 years ago

  • Priority changed from Low to Normal

SLE 15 SP1 will be released soon, so we should try to finish this task and proceed with automation for SP2 later.

Actions #23

Updated by riafarov almost 5 years ago

  • Due date changed from 2019-06-04 to 2019-06-18
Actions #24

Updated by riafarov almost 5 years ago

  • Description updated (diff)
  • Estimated time set to 8.00 h
Actions #25

Updated by JERiveraMoya almost 5 years ago

  • Assignee set to JERiveraMoya
Actions #26

Updated by riafarov almost 5 years ago

  • Description updated (diff)
Actions #27

Updated by JERiveraMoya almost 5 years ago

  • Status changed from Workable to In Progress
  1. Partitionless physical volume with btrfs -> http://rivera-workstation.suse.cz/tests/2817#step/verify_disk_as_pv/10 (current autoyast test suite) -> OK
  2. Partitionless physical volume with ext4 -> http://rivera-workstation.suse.cz/tests/2818#step/verify_disk_as_pv/10 -> OK
  3. Volume group on multiple partitions -> It is not related with this feature due we want to focus on PVs. -> SKIP
Actions #28

Updated by JERiveraMoya almost 5 years ago

Moved focus to Expert Partitioner due to autoyast scenarios were covered by @riafarov a time ago.
I will start using with SLE-15-SP5 without registration.
Performed installation with Expert Partitioner configuring same setup than in autoyast test suite and arriving to the very same result when the proposal is displayed and exactly same output in the command line in the installed system when running lvmdiskscan.
(4) volume group on multiple disks: With Expert Partitioner I used same setup than previous one described, except that I moved /home to another disk (using in total 4 disks) and leaving the vg only with SWAP, the final result is the same I confused initially which is IN the LVM and what is OUT, in our autoyast test suite we left out of the LVM a full disk for root without gpt table, which is not available for LVM) and when we check with lvmdiskscan we got "1 LVM physical volume whole disks" which is referring to the disk that we use for LVM with /home and /swap.
Therefore to test (4) I didn't add a mount point for dev/sdb, which makes this disks available for LVM, I added as PV to LVM and then I created three volume groups. The result is reasonable as I got "2 LVM physical volume whole disks" in the installed system.

**Note regarding (1) and (2): Something that I noticed after this IN/OUT of LVM reasoning in (4) is that suggestion (1) or (2) do not makes sense, because once dev/sdb, which is formatted with btrfs or ext4, is added to LVM as a PV then the format attribute is clean up, which I guess makes sense because afterward creating LVM is when user decides formatting and mount point.
So I tried (1) creating GPT and one Btrfs partition dev/sdb1 and behavior is similar, the partition is not available for LVM when is set the mount point, and once the mount point is clean it and we can add the partition the format is override/cleaned up from btrfs to LVM.

Actions #29

Updated by JERiveraMoya almost 5 years ago

After discussion about (1) and (2) yes, it makes sense but they are not related with LVM, they are testing that a partitionless disk formatted can be included in the partition proposal.
(3) is the nominal case, to have LVM with VGs on multiple partition and that is working from a lot time ago. -> SKIP
(5) 1-4 with encrypted lvm (for VG):

  • (5.1): Replicated with Expert Partitioner exactly the same configuration than for autoyast profile except that dev/sdb (which is out of the LVM) was encrypted. I got after reboot a "Please enter the password for disk crb_vdb!" which accept the corresponding password for the encryption (of course not the user or user root one)-> OK
  • (5.2): Same than (5.1) but /dev/vdc/ (which is in the LVM) was encrypted. Expectation about two different passwords are fulfilled along with having '1 LVM physical volume whole disks'. -> OK (6) 1-4 with encrypted lvm and encrypted partitions in VG:
  • (6.1): Same than (5.2) but encrypting LVs /home and /swap in VG (named 'system'). Expectation about 4 different passwords are met along with having '1 LVM physical volume whole disks'. -> OK
  • (6.2): Same than (4), so getting as base autoyast profile, /dev/sda stays the same, /dev/sdb and /dev/sdc are encrypted but not formatted. LVM is created using both PVs and LVs home, swap and root are created encrypted on top. Expectation about 5 different passwords prompted to user are met along with having '2 LVM physical volume whole disks'. -> OK

**note: I noticed that in the table displayed for LVs there is not column to see if it is encrypted (it would be helpful)

Actions #30

Updated by JERiveraMoya almost 5 years ago

(7) VG with a disk and lvm partition: VG /dev/system utilizes as PVs, one partition /dev/vdc1 (gpt created previously in /dev/vdc) and one full disk /dev/vdb. 3 LVs are created on top for home, swap and root. Expectation in the installed system are met with '1 LVM physical volume whole disks' and '1 LVM physical volume' -> OK
(8) Activation of the disk partitions by installer when having a disk with installations from 1-7: Installed system over the setup created in (6.2). When installer is probing hard disks, Encrypted Volume Activation screen dialog is displayed 5 times as expected -> OK

Actions #31

Updated by JERiveraMoya almost 5 years ago

(9) At least perform one autoyast re-installation: I picked configuration in (7) which it is a LVM configuration where VGs are on top of one full disk and one lvm partition (but this time using a registered system to have YaST System Administration available). The results are similar. -> OK

  1. Whole disk as a single partition -> in (7) and (9) besides a whole disk I'm using a partition which occupies the whole disk, so it is already tested. -> OK
  2. Special disks (DASD, ZFCP, iSCSI): I don't know how to use special type of disks -> ?
  3. Repeat some of the suggestions using Expert Partitioner in the installed system. Using (7) as installed system in texmode I was trying to create same kind of configuration but in this case /root cannot be changed and partitiones controlled by LVM cannot be changed neither, so I didn't find any interesting scenario. -> ?

Regarding automation, perhaps (7) is interesting given than have two different types of PVs.

Actions #32

Updated by JERiveraMoya almost 5 years ago

I used TW and Leap to replicate the same setup than in existing autoyast profile and setup in (7) as well. -> OK

Actions #33

Updated by JERiveraMoya almost 5 years ago

  • Status changed from In Progress to Feedback

Waiting for feedback before to resolve it.

Actions #34

Updated by JERiveraMoya almost 5 years ago

  • Status changed from Feedback to Resolved
Actions #35

Updated by JERiveraMoya almost 5 years ago

  • Copied to action #53243: [functional][y] Automate scenario for full disk as LVM PV added
Actions

Also available in: Atom PDF