Open gboutry opened 1 year ago
Let's figure out if we can express the dependencies properly so that we first create the VLAN without DHCP, then create a subnet with IP ranges, then finally go back and turn on DHCP for the VLAN.
I was thinking a solution that involves the development of a new resource named e.g. maas_vlan_dhcp
and the removal of field dhcp_on
from maas_vlan
. While the ip_ranges
field of the new resource is not going to be used in any HTTP call to MAAS it is enough to capture the dependency. Special care will be made to check that the given ranges are of type dynamic
. The same can be achieved if we let the dependency come through depends_on meta-argument but could complicate things with deletion.
In the below snippet I have included a demonstration of the new resource.
NOTES:
ip_ranges
inside a maas_subnet
. A complete solution will do one of the two things:
maas_subnet
embedded ip_ranges
field and keep only the separated resource maas_subnet_ip_range
. Breaking change but cleanersubnets := list(subnet_ids)
to define dependencies either through it or through ip_ranges
to the new resource maas_vlan_dhcp
.Opinions?
data "maas_vlan" "vlan" {
fabric = "fabric-0"
vid = 100
}
data "maas_vlan" "relay_vlan" {
fabric = "fabric-0"
vid = 0
}
data "maas_rack_controller" "controller_primary" {
name = "maas-dev-1"
}
data "maas_rack_controller" "controller_secondary" {
name = "maas-dev-2"
}
resource "maas_subnet" "subnet_1" {
fabric = data.maas_fabric.fabric.id
vlan = data.maas_vlan.id
name = "test_subnet"
cidr = "10.77.77.0/24"
gateway_ip = "10.77.77.1"
dns_servers = [
"1.1.1.1",
]
}
resource "maas_subnet_ip_range" "dynamic_ip_range_1_1" {
subnet = maas_subnet.subnet_1.id
type = "dynamic"
start_ip = "10.77.77.2"
end_ip = "10.77.77.60"
}
resource "maas_subnet_ip_range" "dynamic_ip_range_1_2" {
subnet = maas_subnet.subnet_1.id
type = "dynamic"
start_ip = "10.77.77.61"
end_ip = "10.77.77.120"
}
resource "maas_vlan_dhcp" "dhcp" {
vlan = data.maas_vlan.id
ip_ranges = [
maas_subnet_ip_range.dynamic_ip_range_1_1,
maas_subnet_ip_range.dynamic_ip_range_1_2,
]
// Optional additional field
// subnets = [
// maas_subnet.subnet_1.id,
// ]
// Optional
relay_vlan = data.maas_vlan.relay_vlan.id
// XOR
primary_rack_controller = data.maas_rack_controller.controller_primary.id
secondary_rack_controller = data.maas_rack_controller.controller_secondary.id
}
I was thinking a solution that involves the development of a new resource named e.g.
maas_vlan_dhcp
and the removal of fielddhcp_on
frommaas_vlan
.
IIUC users will have to pick one of:
maas_vlan_dhcp
(like as it would be maas_vlan
with dhcp_on = true
)maas_vlan
(same as dhcp_on = false
)I am wondering how it will be possible to "enable/disable DHCP on certain VLAN" in this case?
This approach is not taking into consideration the existing embedded
ip_ranges
inside amaas_subnet
. A complete solution will do one of the two things:
- Remove the
maas_subnet
embeddedip_ranges
field and keep only the separated resourcemaas_subnet_ip_range
. Breaking change but cleaner- Define an optional field
subnets := list(subnet_ids)
to define dependencies either through it or throughip_ranges
to the new resourcemaas_vlan_dhcp
.
I like the idea with maas_subnet_ip_range
I was thinking a solution that involves the development of a new resource named e.g.
maas_vlan_dhcp
and the removal of fielddhcp_on
frommaas_vlan
.IIUC users will have to pick one of:
1. `maas_vlan_dhcp` (like as it would be `maas_vlan` with `dhcp_on = true`) 2. `maas_vlan` (same as `dhcp_on = false`)
I am wondering how it will be possible to "enable/disable DHCP on certain VLAN" in this case?
Not exactly that, but close to that. With the proposed solution, DHCP of a VLAN is decoupled of its lifecycle. So maas_vlan
will be used only to create/update/delete VLAN except its DHCP related configuration. For DHCP only config, the new resource maas_vlan_dhcp
will be used.
The existence of this new resource will mean DHCP is enabled to the VLAN, linked by id. To achieve that, user has to additionally define the primary rack controller which will serve the DHCP. A secondary rack controller can be to defined with the relevant optional field.
In case user wants to enable DHCP by relay VLAN, instead of providing a primary rack (+ optional secondary), they have to set the relay_vlan
ID.
The deletion of a maas_vlan_dhcp
resource will mean that DHCP is no longer available to that VLAN, so let's disable it.
We are also impacted by this feature request. We're using this Terraform provider to manage our reasonably large maas deployment of about 1500 vlans and about 1000 machines per site and would greatly benefit from being able to define a maas_vlan_dhcp
resource with DHCP relay configuration in relay_vlan
or direct to rack controller in rack_controller
parameters.
This would save us a lot of toil and keep all MAAS configuration defined inside our Terraform repo instead of in ancillary scripts.
With no understanding of the project and feature timeline, I am wondering if there is a process and/or potential for us to contribute to this feature via PR ?
Terraform Version
Affected Resource(s)
Please list the resources as a list, for example:
Terraform Configuration Files
Expected Behavior
Terraform's apply succeeds on the first run.
Actual Behavior
The plan fails with the following error:
If I set
dchp_on = false
, on the first apply, then totrue
on the second, it works.Steps to Reproduce
Please list the steps required to reproduce the issue, for example:
terraform apply