Dynamic Storage Operations

[sempervictus]

In order to handle machines coming and going in the state file, dynamic enumeration of MaaS' state via data elements is required for all resources to be configured based on what MaaS knows about at the time of execution - meta-programming for inconsistent state of back-end of sorts. The following is done in openstack but can be achieved with vars instead of resource references to the ostack instances:

resource "maas_machine" "metal-1" {
  for_each = openstack_compute_instance_v2.metal-1
  power_type = "manual"
  power_parameters = jsonencode({})
  pxe_mac_address = each.value.network[0].mac
  hostname = each.value.name
  domain = trimsuffix(var.dns_zone_outside, ".")
}
data "maas_network_interface_physical" "metal-1-enp3s0" {
  for_each = maas_machine.metal-1
  machine = each.value.id
  name    = "enp3s0"
}
data "maas_network_interface_physical" "metal-1-enp3s1" {
  for_each = maas_machine.metal-1
  machine = each.value.id
  name    = "enp3s1"
}

which then allows us to use the attributes of data.maas_network_interface_physical.metal-1 to configure resources using the attributes extracted for bond building or what-not.

The same pattern can't be followed when defining storage because there is no data element for block storage devices. Furthermore, the analog to a bond setup on two NICs would be an MDRAID or ZFS mirror (IIRC the latter isn't something MaaS does without custom Curtin config) which don't appear to be configurable through the provider at all.

In order to make this possible, requesting implementation of the following:

1. data element for block devices to permit dynamic composition through iterators
2. support for the storage types which can be configured through UI/pre-made CLI endpoints (LVM, MDRAID, basic ZFS, etc).
3. ideally, at some point, support for custom Curtin configs to do things like advanced ZFS setups

[sempervictus]

Part 1 should be done now - #200