Skip to content

Conversation

@ancorgs
Copy link
Contributor

@ancorgs ancorgs commented Apr 2, 2025

Problem

We recently added support for LVM to the storage section of the web interface. But we lacked time to polish some details like:

  • It's too easy to end up with a configuration without drives as a result of deleting a volume group.
  • Moving the initial partition-based setup to an LVM is not as obvious as we wanted it to be.

Additionally, the current interface is problematic when the name of a disk is too long (eg. multipath devices) or when there are too many disks to choose from.

Solution

This reorganizes the menus a bit to improve the overall situation, although it probably does not fully fix any of the problems in a definitive way.

  • First of all, it identifies the disks using their basenames instead of full device names. See more about device names below. In addition, this truncates very long base names to 17 characters at several places (although it uses a wrong approach). These changes do not fully fix the existing problems with long names but mitigates them to some extend.
  • This also redefines the action to delete an LVM specification. If possible, the system now will move the LVs as partitions to the underlying disk. If that is not possible (multiple underlying disks) or there are no LVs defined, then some sensible deletion of the underlying drives comes into place. That will never lead to the deletion of drives that are used for other purposes or to a setup with no drives.
  • The menu to change the target of a drive was extracted to a new component DriveDeviceMenu and its options were reorganized:
    • Now the option to change the disk is isolated into its own submenu. That's more clear and should also help to handle scenarios with many disks in the future.
    • An option to create an LVM in the disk was added. That should ease the creation of LVM-based setups without the user visiting the "more devices" menu.

Implementation details

  • The new DriveDeviceMenu and the already existing ConfigureDeviceMenu components are now based on new core/MenuButton component. More menus could be adapted in the future.

Pending

  • Maybe: Add new unit tests

About device names

Most disks have a device name like /dev/sda or /dev/nvme0n1. But if multipath is activated with its default configuration, every disk will get a name that is based on a world-wide unique WWID. See some examples of disks and partition names taken from a real system in which multipath was activated:

/dev/mapper/360050768028383d7f000000000000195
/dev/mapper/360050768028383d7f000000000000196
/dev/mapper/360050768028383d7f000000000000197
/dev/mapper/360050768028383d7f000000000000198
/dev/mapper/360050768028383d7f000000000000199
/dev/mapper/360050768028383d7f00000000000019a
/dev/mapper/360050768028383d7f000000000000195-part1
/dev/mapper/360050768028383d7f000000000000195-part2
/dev/mapper/360050768028383d7f000000000000195-part3
/dev/mapper/360050768028383d7f000000000000195-part4
/dev/mapper/360050768028383d7f000000000000196-part1
/dev/mapper/360050768028383d7f000000000000196-part2

@ancorgs ancorgs changed the title Reorganize the drive menus Reorganize and redefine some storage menus Apr 4, 2025
- The menu sets the aria-current property to the expanded item.
- Useful for unit tests to detect whether a submenu is expanded.
- Note that #toBeVisible cannot be used because Jsdom does not
  report correct styles, see jsdom/jsdom#2986.
- Avoid repeating the size of the drive name.
@ancorgs
Copy link
Contributor Author

ancorgs commented Apr 15, 2025

The part about avoiding the hardcoded "20" for the truncates is just partially done. At the time of writing this comment there are another 4 occurrences that were overlooked (at several components like DriveDeviceMenu, LvmPage, PartitionPage or VolumeGroupEditor.

I will try to commit an alternative solution.

@ancorgs
Copy link
Contributor Author

ancorgs commented Apr 15, 2025

I will try to commit an alternative solution.

Done.

dgdavid added 5 commits April 15, 2025 14:40
Basically by removing the gray background originally used to distinguish
them from standard toggles. This background is no longer necessary for
indicating interactivity, and removing it results in a cleaner, more
consistent interface.
And use it for adding the agm-inline-menu-toggle CSS class when needed.
Since toggle are using now the default caret.
Copy link
Contributor

@dgdavid dgdavid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left just a couple of minor notes, but overall it looks really good.

Thanks for handling the creation of the MenuButton core component. It looks solid and should help a lot with centralizing the code for building PatternFly menus more easily.

} from "@patternfly/react-core";
import { _ } from "~/i18n";

/** PF complains with ids generated by useId because they contain colons. Such ids cannot be used
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth to mention that useId() is actually generating an identifier that is a valid HTML id attribute but not a valid CSS identifier. Unfortunately, PatternFly component is querying the node by using the querySelector JavaScript method without escaping the id (by using CSS.escape() for example).

https://github.com/patternfly/patternfly-react/blob/51f35a918102ae3dcaec8ee577cf6f2f578aea16/packages/react-core/src/components/Menu/Menu.tsx#L157

That's why just using the identifier returned by useId is crashing with

Uncaught SyntaxError: Failed to execute 'querySelector' on 'Element': '#:r20:' is not a valid selector. at MenuBase.handleDrilldownTransition (Menu.js:34:1)


interface MenuButtonItemProps extends Omit<MenuItemProps, "direction" | "drilldownMenu"> {
items?: React.ReactNode[];
upProps?: { label?: string };
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the future, I'd allow more MenuItem props for being able to influence such an item easily.

@joseivanlopez joseivanlopez marked this pull request as ready for review April 16, 2025 05:36
joseivanlopez

This comment was marked as resolved.

Co-authored-by: David Díaz <[email protected]>
@ancorgs ancorgs merged commit cdcf13e into agama-project:master Apr 16, 2025
1 check passed
@imobachgs imobachgs mentioned this pull request Apr 22, 2025
imobachgs added a commit that referenced this pull request Apr 22, 2025
bmwiedemann pushed a commit to bmwiedemann/openSUSE that referenced this pull request Apr 23, 2025
https://build.opensuse.org/request/show/1272125
by user IGonzalezSosa + anag_factory
- Version 14

- Process the product changed event so the UI can better react on
  registering the product shortly after that
  (gh#agama-project/agama#2274)

- Rework the network page to (gh#agama-project/agama#2247):
  - Fix several problems with Wi-Fi networks handling.
  - Improve error reporting when the connection failed.
  - Use a regular form to connect, instead of the old "drawer"
    component.
  - Drop the "disconnect" and "forget" actions by now.
  - Reduce the amount of requests to the backend.

- Shorten storage device names.
- Move LVM logical volumes to partitions, if possible.
- Add MenuButton component (gh#agama-project/agama#2241).

- Improve the interface to display and edit the iSCSI initiator
  (bsc#1239046, bsc#1231385, gh#agama-project/agama#2269).

- Fix flickering i
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants