#351 More comprehensive anaconda webUI testing for Fedora 42
Opened 2 months ago by adamwill. Modified 8 days ago

As of today's FESCo meeting (logs pending), the anaconda webUI change is approved for F42. That means we need to substantially expand the scope of testing on it to be as close as possible to the testing done on gtkui, since it'll be present in a release-blocking path. Right now we just run one very simple install test, essentially a smoke test. We need to cover all the partitioning stuff that webUI is capable of, and anything else the UI exposes. This will be a substantial chunk of work.


@kkoukiou is the best contact for you if you need anything

So I did some very preliminary poking about at this today. Tentative conclusion: I think we can just kinda use the existing partition test loading logic in main.pm, which is pretty simple:

    ## Disk partitioning.
    # If PARTITIONING is set, we pick the storage test
    # to run based on the value (usually we run the test with the name
    # that matches the value, except for a couple of commented cases).
    my $storage = '';
    my $partitioning = get_var('PARTITIONING');
    # if PARTITIONING is unset, or one of [...], use disk_guided_empty,
    # which is the simplest / 'default' case.
    if (!$partitioning || $partitioning ~~ ['guided_empty', 'guided_free_space']) {
        $storage = "tests/disk_guided_empty.pm";
    }
    else {
        $storage = "tests/disk_" . $partitioning . ".pm";
    }
    autotest::loadtest $storage;

    if (get_var("ENCRYPT_PASSWORD")) {
        autotest::loadtest "tests/disk_guided_encrypted.pm";
    }

So we can have tests named disk_webui_btrfs_preserve_home with PARTITIONING set to webui_btrfs_preserve_home, disk_webui_delete_partial with PARTITIONING set to webui_delete_partial and so on. I think that should mostly work fine.

These are the possible flows through current webUI partitioning:

  • "Reinstall Fedora" - new thing, doesn't exactly exist in gtkui, effectively matches the "btrfs_preserve_home" tests but is much simpler. Only available if there's an existing Fedora install, has no options
  • "Use entire disk" - equivalent to disk_guided_empty or disk_guided_delete_all in gtkui, if there's an empty disk or the existing disk does not have enough space to install Fedora. Has choice to allow encryption or not
  • "Share disk with other operating system" - equivalent to disk_guided_delete_partial , more or less; it's present if an existing OS is detected(? - maybe just if any data is on the disk?) and takes you through the guided space reclamation UI (mandatory if there isn't enough space on the disk for Fedora)
  • "Mount point assignment" - this is basically custom, except there's no partitioning, just assigning mounts to partitions. For full "custom", you first click the kebab menu at top right and do "Launch storage editor" to get a disk editor, do your editing, save it, then come here

So looking at existing tests...um...

  • install_blivet_*: Launch storage editor -> Mount point assignment
  • install_btrfs: N/A, equal to a default install of Workstation
  • install_btrfs_preserve_home: Reinstall Fedora
  • install_delete_partial: Share disk with other operating system
  • install_delete_pata: Use entire disk
  • install_lvm_ext4: Launch storage editor -> Mount point assignment
  • install_lvmthin: Launch storage editor -> Mount point assignment
  • install_multi: Use entire disk
  • install_multi_empty: Use entire disk or Launch storage editor -> Mount point assignment (not sure, I can't get a multi-disk VM out of Boxes)
  • install_resize_lvm: Launch storage editor -> Mount point assignment
  • install_sata: Use entire disk
  • install_scsi_updates_img: Use entire disk
  • install_shrink_ext4: Share disk with other operating system
  • install_shrink_ntfs: Share disk with other operating system
  • install_simple_encrypted: Use entire disk, then enable encryption
  • install_simple_free_space: Share disk with other operating system, if it's visible (this tests installing to just the free space on a disk with a single, small existing partition)
  • install_software_raid: Launch storage editor -> Mount point assignment
  • install_standard_partition_ext4: Launch storage editor -> Mount point assignment
  • install_with_swap: Launch storage editor -> Mount point assignment
  • install_xfs: Launch storage editor -> Mount point assignment

So...that looks kinda manageable, on the whole. And it shouldn't be too hard for us to split up the work as it doesn't need much co-ordination. We do probably want a library with functions for doing stuff in the "custom" workflow, though, like we do for gtkui custom and blivet. We can add those to anaconda.pm or have a new one.

@lruzicka wdyt?

I started working on this today on the webui-custom branch, but ran into a couple of anaconda bugs that are sort of throwing a spanner in the works: https://bugzilla.redhat.com/show_bug.cgi?id=2336488 and https://bugzilla.redhat.com/show_bug.cgi?id=2336489 . I don't really want to put a bunch of logic in the tests to work around those, hopefully we can get quick fixes instead. @kkoukiou heads up

Yeah, thank you for the exhaustive exploration of the topic. I did not go through all of the tests per se, just through the provided list of yours, I have a couple of remarks so far:

  1. You say the install_btrfs is N/A because it is a basic installation type, however with GTK, with would use Custom or Blivet to install Btrfs anyway, even if it was the basic installation type even before. Should we not also create Btrfs using the Launch storage editor to cover that test?
  2. I could create two drives in VirtManager and I can confirm that with Use entire disk, you can install on two empty drives. You can also do another installation that deletes both of the drives and install a new system, or you can attempt for Reinstall Fedora and preserve home with the two drives, too.

Log in to comment on this ticket.

Metadata