action #40682
closedcoordination #40469: [functional][y][epic] Adjust RAID/LVM/partitioning tests to the new changes and extend testing coverage
[functional][y] full disk as LVM PV
0%
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¶
- Functionality is tested manually using TW, Leap 15.1, SLE 15 SP1 which contain changes
- Draft test plan for the feature is created
- 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:
- Partitionless physical volume with btrfs
- Partitionless physical volume with ext4
- volume group on multiple partitons
- volume group on multiple disks
- 1-4 with encrypted lvm (for VG)
- 1-4 with encrypted lvm and encrypted partitions in VG
- VG with a disk and lvm partition
- Activation of the disk partitions by installer when having a disk with installations from 1-7
- 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
- Whole disk as a single partition
- Special disks (DASD, ZFCP, iSCSI)
- 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.
Updated by okurz over 6 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
Updated by okurz over 6 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
Updated by riafarov over 6 years ago
- Description updated (diff)
- Due date set to 2018-10-09
- Status changed from New to Workable
Updated by okurz over 6 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?
Updated by okurz about 6 years ago
- Related to action #42605: [functional][y][autoyast][storage-ng] Test disk directly as PV added
Updated by riafarov about 6 years ago
- Related to deleted (action #42605: [functional][y][autoyast][storage-ng] Test disk directly as PV)
Updated by riafarov about 6 years ago
- Description updated (diff)
- Estimated time set to 13.00 h
Updated by okurz about 6 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
Updated by riafarov about 6 years ago
- Due date changed from 2018-11-06 to 2018-12-04
Updated by riafarov about 6 years ago
- Status changed from Blocked to Workable
- Assignee deleted (
riafarov)
Unblocked, changes in TW, where we can start with new test.
Updated by okurz about 6 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?
Updated by riafarov almost 6 years ago
- Status changed from Blocked to Workable
- Assignee deleted (
okurz)
#42605 resolved
Updated by riafarov almost 6 years ago
- Due date changed from 2019-01-29 to 2019-02-12
Updated by okurz almost 6 years ago
- Related to action #42605: [functional][y][autoyast][storage-ng] Test disk directly as PV added
Updated by okurz almost 6 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?
Updated by riafarov over 5 years ago
- Description updated (diff)
- Estimated time deleted (
13.00 h)
Scope of the ticket was changed, so removed estimate.
Updated by riafarov over 5 years ago
- Target version changed from Milestone 24 to Milestone 25
Updated by riafarov over 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.
Updated by riafarov over 5 years ago
- Due date changed from 2019-06-04 to 2019-06-18
Updated by riafarov over 5 years ago
- Description updated (diff)
- Estimated time set to 8.00 h
Updated by JERiveraMoya over 5 years ago
- Status changed from Workable to In Progress
- Partitionless physical volume with btrfs -> http://rivera-workstation.suse.cz/tests/2817#step/verify_disk_as_pv/10 (current autoyast test suite) -> OK
- Partitionless physical volume with ext4 -> http://rivera-workstation.suse.cz/tests/2818#step/verify_disk_as_pv/10 -> OK
- Volume group on multiple partitions -> It is not related with this feature due we want to focus on PVs. -> SKIP
Updated by JERiveraMoya over 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.
Updated by JERiveraMoya over 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)
Updated by JERiveraMoya over 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
Updated by JERiveraMoya over 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
- 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
- Special disks (DASD, ZFCP, iSCSI): I don't know how to use special type of disks -> ?
- 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.
Updated by JERiveraMoya over 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
Updated by JERiveraMoya over 5 years ago
- Status changed from In Progress to Feedback
Waiting for feedback before to resolve it.
Updated by JERiveraMoya over 5 years ago
- Status changed from Feedback to Resolved
Updated by JERiveraMoya over 5 years ago
- Copied to action #53243: [functional][y] Automate scenario for full disk as LVM PV added
Updated by JERiveraMoya over 5 years ago
Follow-up ticket: https://progress.opensuse.org/issues/53243