1) Subnet F3CR6SWT Vlan601 (id=429) state prior to change:
cidr: 10.86.112.64/26
gateway: 10.86.112.65
in vlan: 601 (id=5452)
in fabric: AV25 (id=403)
with reserved iprange 10.86.112.65-10.86.112.67
and dynamic iprange 10.86.112.112-10.86.112.126
displayed subnet address available: 62
2) Changes made:
subnet_args = { 'name'=>'F3CR6SWT Vlan601', 'cidr'=>'10.86.112.0/26', 'gateway_ip'=>'10.86.112.1', 'vlan'=>5492 }
send PUT to '/MAAS/api/2.0/subnets/429/' with subnet_args
res_args = { 'type'=>'reserved', 'start_ip'=>'10.86.112.1', 'end_ip'=>10.86.112.3', 'subnet'=>429 }
send POST to '/MAAS/api/2.0/ipranges/' with res_args
dyn_args = { 'type'=>'reserved', 'start_ip'=>'10.86.112.48', 'end_ip'=>10.86.112.62', 'subnet'=>429 }
send POST to '/MAAS/api/2.0/ipranges/' with dyn_args
3) Subnet F3CR6SWT Vlan601 (id=429) state after change:
cidr: 10.86.112.0/26
gateway: 10.86.112.1
in vlan: 601 (id=5492)
in fabric: AV13 (id=438)
with reserved ipranges 10.86.112.65-10.86.112.67 and 10.86.112.1-10.86.112.3
and dynamic ipranges 10.86.112.112-10.86.112.126 and 10.86.112.48-10.86.112.62
displayed subnet address available: 126
**Our intention was to send a POST to '/MAAS/api/2.0/subnets/' with subnet_args rather than the PUT to '/MAAS/api/2.0/subnets/429', but we forgot to update the subnet name in the call. That's our bug to fix.
However, the original ipranges in the subnet are now illegal as a result of the cidr change, and the subnet address calculation is incorrect. I would expect an error from MAAS in these cases. Perhaps validate existing gateway and ipranges in a subnet on a cidr change?
Sure,
1) Subnet F3CR6SWT Vlan601 (id=429) state prior to change: 65-10.86. 112.67 112-10. 86.112. 126
cidr: 10.86.112.64/26
gateway: 10.86.112.65
in vlan: 601 (id=5452)
in fabric: AV25 (id=403)
with reserved iprange 10.86.112.
and dynamic iprange 10.86.112.
displayed subnet address available: 62
2) Changes made: >'10.86. 112.0/26' , 'gateway_ ip'=>'10. 86.112. 1', 'vlan'=>5492 } api/2.0/ subnets/ 429/' with subnet_args
subnet_args = { 'name'=>'F3CR6SWT Vlan601', 'cidr'=
send PUT to '/MAAS/
res_args = { 'type'=>'reserved', 'start_ ip'=>'10. 86.112. 1', 'end_ip' =>10.86. 112.3', 'subnet'=>429 } api/2.0/ ipranges/ ' with res_args
send POST to '/MAAS/
dyn_args = { 'type'=>'reserved', 'start_ ip'=>'10. 86.112. 48', 'end_ip' =>10.86. 112.62' , 'subnet'=>429 } api/2.0/ ipranges/ ' with dyn_args
send POST to '/MAAS/
3) Subnet F3CR6SWT Vlan601 (id=429) state after change: 65-10.86. 112.67 and 10.86.112. 1-10.86. 112.3 112-10. 86.112. 126 and 10.86.112. 48-10.86. 112.62
cidr: 10.86.112.0/26
gateway: 10.86.112.1
in vlan: 601 (id=5492)
in fabric: AV13 (id=438)
with reserved ipranges 10.86.112.
and dynamic ipranges 10.86.112.
displayed subnet address available: 126
**Our intention was to send a POST to '/MAAS/ api/2.0/ subnets/ ' with subnet_args rather than the PUT to '/MAAS/ api/2.0/ subnets/ 429', but we forgot to update the subnet name in the call. That's our bug to fix.
However, the original ipranges in the subnet are now illegal as a result of the cidr change, and the subnet address calculation is incorrect. I would expect an error from MAAS in these cases. Perhaps validate existing gateway and ipranges in a subnet on a cidr change?