Comment 4 for bug 1901719

Sure,

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?