Comment 2 for bug 1510338

@Zane Bitter:
The allocation_pools of subnet are ip pools that used to assign ip address automatically to port if user don't specify the ip_address(when port creation), other ips outside the allocation_pools also belong to the subnet, and we can assign them to port if specified when port-create.
And if there is any port in subnet, we can't delete the subnet, this means we can't replace the subnet in this situation.
Also, I think it's not good to do these complex logic validation in heat, if neutron doesn't allow to update the allocation_pools in some situations, we just to raise the error and set to stack to FAILED, right?

In fact, there is an other case I don't know how to do fix when updating the allocation_pools in my patch:
1. subnet-create: If user don't specify 'allocation_pools' property in template, we won't pass the parameter to neutron, so neutron set the allocation_pools with default start ip_address and end ip_address. ------ok
2. to update the allocation_pools with some ranges [{start: ip1, end: ip2}, ...] -------ok
3. to update again, don't specify 'allocation_pools' property in template again, what should I do now? if to pass allocation_pools=[](or None) to neutron, then the subnet will no allocation_pools(the behavior is not the same as creation); if not pass the 'allocation_pools' to neutron, neutron won't update the allocation_pools.