[rfe] update CIDR for subnet

What is your use case? Usually there are good reasons for making certain resources immutable, like the CIDR on a subnet.

This would have to be pretty restrictive, I think. PD kind of gets away with it because there is a mechanism for disseminating the new subnet to hosts on the subnet in IPv6 router advertisements.

IPv4 really doesn't have a good mechanism. DHCP would be terrible for this. You'd have a long period of time where you would need to expect things to just not work as all the various ports on the subnet are updated through DHCP and RPC (router ports, DHCP server ports, etc). There is no way that I'm aware of to reliably trigger a forced update to DHCP clients.

So, this would have to be restricted to IPv6 subnets where RA is used to be viable at all. Even then, what's the point? You can always add a second IPv6 subnet to the network and then delete the first one. Have you tried that to satisfy your use case?

I'm going to mark this incomplete until a good use case is described.

I want to expand or shrink Public or Provider network CIDR (and thus range) without re-allocating all IPs.

Adding new Subnet and deleting old one is not working until all Ports are updated to use address from new Subnet. Also, there is no way to set overlapping Subnet this way.

I'm aware of the fact that updating IPv4 addresses on VMs is barely possible. However, Neutron allows it with port-update mechanism, so I see no difference between allowing operator to change Fixed (Floating) IP for single port, and for many ports.

I don't think a port update works on a bound port.

Also, you can grow the address space by adding a second subnet. We don't have a way to shrink a subnet.

You don't have to delete anything, just add aside the existing subnets. Besides, altering a longstanding contract may have unexpected side effects on plugins that do not handle well the CIDR update. For that reason, I am compelled to mark this WONTFIX, but let's raise it for wider discussion.

Update on bound port is working, this mechanism is exactly what is using for:

  1. DHCPv6 PD,
  2. When you update IP for VM,
  3. When you're moving your VMs into new subnet.

So there is no way port update will break anything. The only valid implication here is "unexpected side effects on plugins that do not handle well the CIDR update".

On 2013, Neutron was not able to update allocation pools, but now it can. So I don't see any reasons to withdrawn this idea completely.

I think with randomized ip allocations, you can't really reliably shrink a pool anymore. As for expansion, you already have an option to add a new pool. So the benefit here is pretty low for what I wonder.

I would suggest not to give much priority to this proposal.

If your network administrator will change network on hardware router, say, from 10.0.0.0/24 to 10.0.0.0/23, you will not able to add new subnet any way, because they are overlapping.

Change abandoned by Armando Migliaccio (<email address hidden>) on branch: master
Review: https://review.openstack.org/345594
Reason: This review is > 4 weeks without comment and currently blocked by a core reviewer with a -2. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and contacting the reviewer with the -2 on this review to ensure you address their concerns.

Vladimir, then add 10.128.0.0/24?

Sorry, 10.0.128.0/24 it is (?).

Nevermind, I screwed the math. :) So yeah, seems like we can't really do it?

This was discussed during the drivers meeting [1]. It sounds like expanding or shrinking the IP space dynamically and doing it reliably can be rather hard. Can you elaborate why adding new subnets to the space wouldn't address your use case?

[1] http://eavesdrop.openstack.org/meetings/neutron_drivers/2017/neutron_drivers.2017-01-19-22.02.log.html

[Expired for neutron because there has been no activity for 60 days.]