Public bug reported: As documented in https://docs.openstack.org/neutron/latest/admin/config- service-subnets.html, subnets can be assigned a service-type which ensures that they are only used to allocate addresses to a specific device owner. But the current implementation also allows this feature to be used to ensure that no addresses at all are assigned from a subnet by setting the service type to an invalid owner like "compute:bogus" or "network:drain".
One use case for this is extending or reducing FIP pools in a deployment. Assume there is a /24 in use as public subnet which is running full. Adding a second /24 is possible, but will waste some IPs for network, gateway and broadcast address. So the better solution will be to add a /23, gradually migrate the existing users away from the /24 and finally remove the old /24. In order for this to be feasible, one must prevent allocation from the old subnet to happen during the migration phase. The same applies when an operator wants to reduce the size of a pool. Since the above solution is undocumented, it would be useful to make it documented and thus ensure that this stays a dependable workflow for operators. Maybe one can also define a well-known "bogus" owner that could be added in case the verification of device owners was to be made more strict. Having some functional testing for this scenario might be an extra bonus. ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2024921 Title: Formalize use of subnet service-type for draining subnets Status in neutron: New Bug description: As documented in https://docs.openstack.org/neutron/latest/admin/config-service- subnets.html, subnets can be assigned a service-type which ensures that they are only used to allocate addresses to a specific device owner. But the current implementation also allows this feature to be used to ensure that no addresses at all are assigned from a subnet by setting the service type to an invalid owner like "compute:bogus" or "network:drain". One use case for this is extending or reducing FIP pools in a deployment. Assume there is a /24 in use as public subnet which is running full. Adding a second /24 is possible, but will waste some IPs for network, gateway and broadcast address. So the better solution will be to add a /23, gradually migrate the existing users away from the /24 and finally remove the old /24. In order for this to be feasible, one must prevent allocation from the old subnet to happen during the migration phase. The same applies when an operator wants to reduce the size of a pool. Since the above solution is undocumented, it would be useful to make it documented and thus ensure that this stays a dependable workflow for operators. Maybe one can also define a well-known "bogus" owner that could be added in case the verification of device owners was to be made more strict. Having some functional testing for this scenario might be an extra bonus. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2024921/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp