Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MTL-1561 Add GCP mode for supporting GCP NVME #15

Merged
merged 1 commit into from
Dec 1, 2021

Conversation

rustydb
Copy link
Contributor

@rustydb rustydb commented Nov 19, 2021

Summary and Scope

Issue Type
  • RFE Pull Request

This new toggle will insert the partitioning prefix into all disks,
assuming that the disks are GCP provided NVME.

This implicitly means that only NVME is supported when gcp-mode is
engaged. We can add logic to handle our full-suite of busses, only if
we have a use in SAS and SATA GCP disks.

Prerequisites

  • I have included documentation in my PR (or it is not required)
  • I tested this on internal system (x) (if yes, please include results or a description of the test)
  • I tested this on vshasta (x) (if yes, please include results or a description of the test)

This needs to be tested on GCP and metal, for the new and old behaviors (respectively).

Idempotency

Risks and Mitigations

This does not bring the full suite of busses to GCP, it only enables NVME for GCP.

@rustydb
Copy link
Contributor Author

rustydb commented Nov 19, 2021

Metal tests succeeded, saw the expected behavior.

@rustydb
Copy link
Contributor Author

rustydb commented Nov 19, 2021

@taylorludwig , once this is tested in GCP with metal.gcp-mode on the cmdline we can merge this.

@rustydb rustydb force-pushed the MTL-1561-support-GCP-NVME branch 2 times, most recently from 7b506ed to 6561407 Compare November 19, 2021 23:04
@wiltonpaulo
Copy link

@taylorludwig , once this is tested in GCP with metal.gcp-mode on the cmdline we can merge this.

I'll test and post results

@wiltonpaulo
Copy link

[   12.662608] dracut-initqueue[681]: + for disk in $md_disks
[   12.673517] dracut-initqueue[681]: + parted --wipesignatures -m --align=opt --ignore-busy -s /dev/nvme0n1 -- mklabel gpt mkpart esp fat32 2048s 500MB set 1 esp on mkpart primary xfs 500MB 25GB
[   12.688164] dracut-initqueue[681]: + _trip_udev
[   12.700192] dracut-initqueue[681]: + udevadm settle
[   12.712372] dracut-initqueue[760]: ++ trim
[   12.713289] dracut-initqueue[760]: ++ local var=
[   12.724117] dracut-initqueue[760]: ++ var=
[   12.736254] dracut-initqueue[760]: ++ var=
[   12.748159] dracut-initqueue[760]: ++ printf %s ''
[   12.760123] dracut-initqueue[681]: + boot_raid_parts=' /dev/nvme0n1p1'
[   12.772430] dracut-initqueue[761]: ++ trim
[   12.784100] dracut-initqueue[761]: ++ local var=
[   12.796103] dracut-initqueue[761]: ++ var=
[   12.808095] dracut-initqueue[761]: ++ var=
[   12.820120] dracut-initqueue[761]: ++ printf %s ''
[   12.832393] dracut-initqueue[681]: + sqfs_raid_parts=' /dev/nvme0n1p2'
[   12.844104] dracut-initqueue[681]: + for disk in $md_disks
[   12.845413] dracut-initqueue[681]: + parted --wipesignatures -m --align=opt --ignore-busy -s /dev/nvme0n2 -- mklabel gpt mkpart esp fat32 2048s 500MB set 1 esp on mkpart primary xfs 500MB 25GB
[   12.860297] dracut-initqueue[681]: + _trip_udev
[   12.872112] dracut-initqueue[681]: + udevadm settle
[   12.884204] dracut-initqueue[764]: ++ trim /dev/nvme0n1p1
[   12.896091] dracut-initqueue[764]: ++ local var=/dev/nvme0n1p1
[   12.908070] dracut-initqueue[764]: ++ var=/dev/nvme0n1p1
[   12.920060] dracut-initqueue[764]: ++ var=/dev/nvme0n1p1
[   12.932070] dracut-initqueue[764]: ++ printf %s /dev/nvme0n1p1
[   12.944190] dracut-initqueue[681]: + boot_raid_parts='/dev/nvme0n1p1 /dev/nvme0n2p1'
[   12.956167] dracut-initqueue[765]: ++ trim /dev/nvme0n1p2
[   12.968067] dracut-initqueue[765]: ++ local var=/dev/nvme0n1p2
[   12.980078] dracut-initqueue[765]: ++ var=/dev/nvme0n1p2
[   12.992120] dracut-initqueue[765]: ++ var=/dev/nvme0n1p2
[   13.004203] dracut-initqueue[765]: ++ printf %s /dev/nvme0n1p2
[   13.016204] dracut-initqueue[681]: + sqfs_raid_parts='/dev/nvme0n1p2 /dev/nvme0n2p2'
[   13.028199] dracut-initqueue[681]: + mdadm --create /dev/md/BOOT --run --verbose --assume-clean --metadata=0.9 --level=mirror --raid-devices=2 /dev/nvme0n1p1 /dev/nvme0n2p1
[   13.040305] dracut-initqueue[766]: mdadm: size set to 480192K
[   13.052142] dracut-initqueue[766]: mdadm: array /dev/md/BOOT started.
[   13.064184] dracut-initqueue[681]: + mdadm --create /dev/md/SQFS --run --verbose --assume-clean --metadata=1.2 --level=mirror --raid-devices=2 /dev/nvme0n1p2 /dev/nvme0n2p2
[   13.076255] dracut-initqueue[781]: mdadm: size set to 23908352K
[   13.088069] dracut-initqueue[781]: mdadm: array /dev/md/SQFS started.

@rustydb rustydb force-pushed the MTL-1561-support-GCP-NVME branch 2 times, most recently from 5d39dd1 to 6e43a93 Compare November 29, 2021 11:47
@rustydb
Copy link
Contributor Author

rustydb commented Nov 29, 2021

[   12.662608] dracut-initqueue[681]: + for disk in $md_disks
[   12.673517] dracut-initqueue[681]: + parted --wipesignatures -m --align=opt --ignore-busy -s /dev/nvme0n1 -- mklabel gpt mkpart esp fat32 2048s 500MB set 1 esp on mkpart primary xfs 500MB 25GB
[   12.688164] dracut-initqueue[681]: + _trip_udev
[   12.700192] dracut-initqueue[681]: + udevadm settle
[   12.712372] dracut-initqueue[760]: ++ trim
[   12.713289] dracut-initqueue[760]: ++ local var=
[   12.724117] dracut-initqueue[760]: ++ var=
[   12.736254] dracut-initqueue[760]: ++ var=
[   12.748159] dracut-initqueue[760]: ++ printf %s ''
[   12.760123] dracut-initqueue[681]: + boot_raid_parts=' /dev/nvme0n1p1'
[   12.772430] dracut-initqueue[761]: ++ trim
[   12.784100] dracut-initqueue[761]: ++ local var=
[   12.796103] dracut-initqueue[761]: ++ var=
[   12.808095] dracut-initqueue[761]: ++ var=
[   12.820120] dracut-initqueue[761]: ++ printf %s ''
[   12.832393] dracut-initqueue[681]: + sqfs_raid_parts=' /dev/nvme0n1p2'
[   12.844104] dracut-initqueue[681]: + for disk in $md_disks
[   12.845413] dracut-initqueue[681]: + parted --wipesignatures -m --align=opt --ignore-busy -s /dev/nvme0n2 -- mklabel gpt mkpart esp fat32 2048s 500MB set 1 esp on mkpart primary xfs 500MB 25GB
[   12.860297] dracut-initqueue[681]: + _trip_udev
[   12.872112] dracut-initqueue[681]: + udevadm settle
[   12.884204] dracut-initqueue[764]: ++ trim /dev/nvme0n1p1
[   12.896091] dracut-initqueue[764]: ++ local var=/dev/nvme0n1p1
[   12.908070] dracut-initqueue[764]: ++ var=/dev/nvme0n1p1
[   12.920060] dracut-initqueue[764]: ++ var=/dev/nvme0n1p1
[   12.932070] dracut-initqueue[764]: ++ printf %s /dev/nvme0n1p1
[   12.944190] dracut-initqueue[681]: + boot_raid_parts='/dev/nvme0n1p1 /dev/nvme0n2p1'
[   12.956167] dracut-initqueue[765]: ++ trim /dev/nvme0n1p2
[   12.968067] dracut-initqueue[765]: ++ local var=/dev/nvme0n1p2
[   12.980078] dracut-initqueue[765]: ++ var=/dev/nvme0n1p2
[   12.992120] dracut-initqueue[765]: ++ var=/dev/nvme0n1p2
[   13.004203] dracut-initqueue[765]: ++ printf %s /dev/nvme0n1p2
[   13.016204] dracut-initqueue[681]: + sqfs_raid_parts='/dev/nvme0n1p2 /dev/nvme0n2p2'
[   13.028199] dracut-initqueue[681]: + mdadm --create /dev/md/BOOT --run --verbose --assume-clean --metadata=0.9 --level=mirror --raid-devices=2 /dev/nvme0n1p1 /dev/nvme0n2p1
[   13.040305] dracut-initqueue[766]: mdadm: size set to 480192K
[   13.052142] dracut-initqueue[766]: mdadm: array /dev/md/BOOT started.
[   13.064184] dracut-initqueue[681]: + mdadm --create /dev/md/SQFS --run --verbose --assume-clean --metadata=1.2 --level=mirror --raid-devices=2 /dev/nvme0n1p2 /dev/nvme0n2p2
[   13.076255] dracut-initqueue[781]: mdadm: size set to 23908352K
[   13.088069] dracut-initqueue[781]: mdadm: array /dev/md/SQFS started.

Great.

Just awaiting a retest with the newer build I sent.

@rustydb
Copy link
Contributor Author

rustydb commented Nov 30, 2021

Testing worked nicely, but reboots with metal.no-wipe=0 ends up failing after the first deploy. This technically is acceptable since we technically do reboots with metal.no-wipe=1 (which was verified to work).

I'm looking at a tiny fix to allow the disk selection to work (and not choose existing partitions). The strange thing is (to think aloud here) the wiping is done before the disk selection and udev is even tripped (here https://github.com/Cray-HPE/dracut-metal-mdsquash/blob/main/90metalmdsquash/metal-md-disks.sh#L21).

@rustydb
Copy link
Contributor Author

rustydb commented Dec 1, 2021

This is actually looking good.
One more test is being done by vshasta-team to verify that the 3rd disk is formatted properly even when metal.gcp-mode is set.

This new toggle will insert the partitioning prefix into all disks,
assuming that the disks are GCP provided NVME.

This implicitly means that only NVME is supported when gcp-mode is
engaged. We can add logic to handle our full-suite of busses, only if
we have a use in SAS and SATA GCP disks.
@rustydb rustydb merged commit 0c1abbe into main Dec 1, 2021
@rustydb rustydb deleted the MTL-1561-support-GCP-NVME branch December 1, 2021 18:32
# PAVE & GO-AROUND/RETRY
[ ! -f /tmp/metalpave.done ] && [ "${metal_nowipe:-0}" != 1 ] && pave

# DISKS; disks were detected, find the amount we need or die. Also die if there are 0 disks.
# MAINTAINER NOTE: We filter out NVME partitions because they'll exist at this point since pave() is called afterwards.
md_disks="$(lsblk -l -o SIZE,NAME,TYPE,TRAN | grep -E '('"$metal_transports"')' | sort -u | awk '{print $2}' | head -n ${metal_disks} | tr '\n' ' ' | sed 's/ *$//')"
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The change of sort -u to sort -h is breaking the sorting of the disks by size and the RAID is going to grab the wrong disks.

+ lsblk
NAME                MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
loop0                 7:0    0   4.7G  1 loop  /run/rootfsbase
loop1                 7:1    0   3.2G  0 loop
`-live-overlay-pool 254:0    0    32G  0 dm
loop2                 7:2    0    32G  0 loop
`-live-overlay-pool 254:0    0    32G  0 dm
sda                   8:0    0 447.1G  0 disk
|-sda1                8:1    0   476M  0 part
| `-md127             9:127  0 475.9M  0 raid1
|-sda2                8:2    0  22.8G  0 part
| `-md126             9:126  0  22.8G  0 raid1 /run/initramfs/live
|-sda3                8:3    0 139.7G  0 part
| `-md125             9:125  0 139.6G  0 raid1 /run/initramfs/overlayfs
`-sda4                8:4    0 139.7G  0 part
  `-md124             9:124  0 139.6G  0 raid1
sdb                   8:16   0   1.7T  0 disk
|-sdb1                8:17   0   476M  0 part
| `-md127             9:127  0 475.9M  0 raid1
|-sdb2                8:18   0  22.8G  0 part
| `-md126             9:126  0  22.8G  0 raid1 /run/initramfs/live
|-sdb3                8:19   0 139.7G  0 part
| `-md125             9:125  0 139.6G  0 raid1 /run/initramfs/overlayfs
`-sdb4                8:20   0 139.7G  0 part
  `-md124             9:124  0 139.6G  0 raid1
sdc                   8:32   0 447.1G  0 disk

Observe above that sdb is the larger, ephemeral disk. However it has been adopted as a RAID member.

@rustydb rustydb restored the MTL-1561-support-GCP-NVME branch December 3, 2021 19:48
rustydb added a commit that referenced this pull request Dec 3, 2021
rustydb added a commit that referenced this pull request Dec 3, 2021
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.

4 participants