Host local storage support

[torchiaf]

Summary

PR Checklist

• Is this a multi-tenancy feature/bug?
  • Yes, the relevant RBAC changes are at:
• Do we need to backport changes to the old Rancher UI, such as RKE1?
  • Yes, the relevant PR is at:
• Are backend engineers aware of UI changes?
  • Yes, the backend owner is:

Related Issue harvester/harvester#6057
Related Issue harvester/harvester#5953

Occurred changes and/or fixed issues

Technical notes summary

Areas or cases that should be tested

Areas which could experience regressions

Screenshot/Video

• Add a LVM disk

• Add LVM storage class

[mergify]

This pull request is now in conflict. Could you fix it @torchiaf? 🙏

[tserong]

I've done some initial testing of this, and provisioning and unprovisioning LHv1 and LHv2 disks seems to work, but I've found two things so far that need tweaking:

1. This PR sets a storageclass parameter named engineVersion with value LonghornV1 or LonghornV2, but it should instead be dataEngine with value v1 or v2 (see https://raw.githubusercontent.com/longhorn/longhorn/v1.7.1/examples/v2/storageclass.yaml for an example of a V2 storage class).

2. spec.fileSystem.provisioned is deprecated in favour of spec.provision, but it seems we're still setting spec.fileSystem.provisioned here. If I use this PR to provision a Longhorn V2 disk for example, then check the BD CR, I get this:

> kubectl -n longhorn-system get bds/989754e4e66edadfd3390974a1aba3f8 -o yaml 
[...]
spec:
  devPath: /dev/sdb
  fileSystem:
    mountPoint: ""
    provisioned: true
  nodeName: harvester-node-0
  provision: false
  provisioner:
    longhorn:
      engineVersion: LonghornV2
[...]

...but it should be:

spec:
  devPath: /dev/sdb
  fileSystem:
    mountPoint: ""
  nodeName: harvester-node-0
  provision: true
  provisioner:
    longhorn:
      engineVersion: LonghornV2

[torchiaf]

Thanks @tserong , the code is now updated to handle the v1/v2 engineVersion in Storage Class page and use the new spec.provision field in blockDevice crd in Disks assignement.

[mergify]

This pull request is now in conflict. Could you fix it @torchiaf? 🙏

[tserong]

Thanks @torchiaf, the spec.provision field is working correctly now.

The StorageClass is not quite right - the v1/v2 value is correct, but the parameter name engineVersion needs to be changed to dataEngine (sorry if this wasn't clear earlier, and I know it's probably a pain that this is a different name than what's in the block device CR).

I also have a question: previously there was a "force formatted" checkbox for Longhorn V1:

...but this isn't present anymore, although there's still a tip about it:

Is this correct?

---

I also have a problem provisioning Longhorn V1 disks. They seem to add successfully, but shortly thereafter, they aren't mounted and are unschedulable. I suspect this is actually a problem in node-disk-manager. I'll report back once I've figured out what's going on with this.

[tserong]

...oh also, one more thing: After a disk is provisioned, do we need to show what provisioner is used when viewing the disks on that node? Because there's no indication of that currently - you just see the disk like this:

@Vicente-Cheng, WDTY? Also, I haven't tested what's shown here in the LVM case.

[torchiaf]

@tserong I've fixed the dataEngine parameter, thanks.

For the other points:

• We don't show the 'Force Formatted' checkbox if the disk has already been formatted. This mechanism is unchanged from master:
  • We show up the Force Formatted warning message if any of the new disks is formatted -> blockDevice.spec.fileSystem.forceFormatted. Could you verify this value? I can't replicate it in my environment.

• Not sure what was the root cause of provisioning errors, let me know if any API parameter from the UI is wrong.

[Vicente-Cheng]

...oh also, one more thing: After a disk is provisioned, do we need to show what provisioner is used when viewing the disks on that node? Because there's no indication of that currently - you just see the disk like this:

@Vicente-Cheng, WDTY? Also, I haven't tested what's shown here in the LVM case.

I checked with the latest changes. It looks like @torchiaf already added the provisioner fields.

I thought the current display looked good to me. WDYT? @tserong

We show up the Force Formatted warning message if any of the new disks is formatted -> blockDevice.spec.fileSystem.forceFormatted. Could you verify this value? I can't replicate it in my environment.

I thought we could keep that, but only for the v1 engine.
For v2 engine, we should not let users select any formatted options.

I also have a problem provisioning Longhorn V1 disks. They seem to add successfully, but shortly thereafter, they aren't mounted and are unschedulable. I suspect this is actually a problem in node-disk-manager. I'll report back once I've figured out what's going on with this.

I will check this... It is not related to UI issue. The CRD fields looks good.
Fixed, PR here: harvester/node-disk-manager#139

BTW, I checked the whole LVM flow, and everything looks fine. Thanks!

[tserong]

Thanks @Vicente-Cheng, @torchiaf! Will re-test this morning.

[a110605]

typo DEFAUL_TOPOLOGIES

[torchiaf]

@tserong @Vicente-Cheng I've changed the AccessMode for LonghornV2 disks and limited the VolumeBindingMode to WaitForFirstConsumer in Storage Classes create page.

[mergify]

This pull request is now in conflict. Could you fix it @torchiaf? 🙏

[tserong]

Thanks @torchiaf, I've just tested and the AccessMode change for LHv2 volumes works fine when the new volumes are created on the Volumes page. For new volumes created while creating virtual machines though (Virtual Machines: Create: Volumes: Add Volume), it's still using ReadWriteMany.

[Vicente-Cheng]

Thanks @torchiaf, I have tested the latest changes.
Looks the VolumeBindingMode works good with WaitForFirstConsumer with StorageClass page.

But I tested the volume creation. The accessMode is still RWX instead RWO. See below

Create Vol002 from UI, then check the accessMode

Could you help to check it again?
Thanks!