Feature Request: Add storage device details of the enlisted machine to Terraform state during commissioning

[vishvikkrishnan]

Currently, the maas_machine resource does not provide details about the storage devices present in the commissioned node. This is unlike network interfaces, which are auto-populated with the MAC addresses of each NIC discovered in the enlisted machine.

# maas_machine.node["node01ob48"] will be created
  + resource "maas_machine" "node" {
      + architecture       = "amd64/generic"
      + domain             = (known after apply)
      + hostname           = "node01ob48"
      + id                 = (known after apply)
      + min_hwe_kernel     = (known after apply)
      + network_interfaces = (known after apply)
      + pool               = (known after apply)
      + power_parameters   = (sensitive value)
      + power_type         = "amt"
      + pxe_mac_address    = "b8:ae:ed:73:38:40"
      + zone               = "default"
    }

After applying the above resource, the following details are available in the TF state:

# maas_machine.node["node01ob48"]:
resource "maas_machine" "node" {
    architecture       = "amd64/generic"
    domain             = "maas"
    hostname           = "node01ob48"
    id                 = "c7xnp8"
    min_hwe_kernel     = null
    network_interfaces = [
        "8c:ae:4c:df:50:7c",
        "b8:ae:ed:73:38:40",
    ]
    pool               = "default"
    power_parameters   = (sensitive value)
    power_type         = "amt"
    pxe_mac_address    = "b8:ae:ed:73:38:40"
    zone               = "default"
}

However, the state file does not track the storage device details, unlike network interface details that are auto-populated. MAAS automatically enlists all storage devices during node enlistment and, by default, selects and partitions the first device from the alphanumerically sorted storage disk list as its boot and / partitions:

Because of this, trying to apply the maas_block_device resource with a different target disk causes an error:

# maas_block_device.disks["node01ob48-sdb"] will be created
  + resource "maas_block_device" "disks" {
      + block_size     = 512
      + id             = (known after apply)
      + id_path        = (known after apply)
      + is_boot_device = false
      + machine        = "node01ob48"
      + model          = "KINGSTON SM2280S"
      + name           = "sdb"
      + path           = (known after apply)
      + serial         = "50026B725A01A663"
      + size_gigabytes = 120
      + tags           = (known after apply)
      + uuid           = (known after apply)

      + partitions {
          + fs_type        = "fat32"
          + mount_point    = "/boot/efi"
          + path           = (known after apply)
          + size_gigabytes = 1
        }
      + partitions {
          + fs_type        = "ext4"
          + mount_point    = "/"
          + path           = (known after apply)
          + size_gigabytes = 90
        }
      + partitions {
          + fs_type        = "ext4"
          + mount_point    = "/home"
          + path           = (known after apply)
          + size_gigabytes = 15
        }
    }

maas_block_device.disks["node01ob48-sdb"]: Creating...
╷
│ Error: ServerError: 400 Bad Request ({"__all__": ["Another filesystem is already mounted at /."]})
│ 
│   with maas_block_device.disks["node01ob48-sdb"],
│   on main.tf line 33, in resource "maas_block_device" "disks":
│   33: resource "maas_block_device" "disks" {
│ 

Since the TF user has no idea which storage device was used by MAAS as the OS device during commissioning, making changes to the storage layout requires one of the following workarounds:

• removing the existing partitions and/or block device and creating new partitions if the same device is to be used -- not very idempotent since user has to know a priori what partitions exist (reading the MAAS DB)
• creating or updating the "imported" storage device to match the desired storage configuration or layout -- simplistic from the user perspective, but complicated on the implementation side with perfect idempotency
• deleting all disks and configuring storage from a clean state for the enlisted node -- this approach is somewhat idempotent, but only after the existing disks/partitions have been removed

We currently work around this by exporting the storage details during node enlistment and using this info to delete all devices and start from scratch -- last suggestion above (and FCE's approach as well), but we could certainly benefit from having the storage details available in the TF state after the maas_machine resource is created which can later be used to guide the maas_block_device resource.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 30 days since being marked as stale.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.