I've been thinking about this for a little while now. There seems to be something different about floating IP subnets and other (I'll call them "service" in this context) subnets in some use cases.
- On an external network where operators wish to use private IPs for router ports (and DVR FIP ports) and public for floating IPs.
- Enable using floating IPs on provider networks without routers [1]. This has come up a lot. In many cases, operators want them to be public while the static ones are private.
- On routed networks where VM instance and router ports need IPs from their segments but floating IPs can be routed more flexibly.
I don't think we need to implement all of these use cases with this RFE. I think this RFE should just solve the first one about router ports. However, all of them seem to all need some way to distinguish different subnets on the same network for different purposes.
Let's add a service type field to the subnet. To start with, we’ll have two possible values other than the current default of null: "dvr_gateway", and "dvr_and_router_ports". The names aren’t written in stone. The choice between the two depends on if you want your routers to get public addresses for SNAT. IPAM will consider the service type when allocating a port for a particular device_owner. Each device_owner will have a (possibly empty) list of service types to prefer.
Any kind of port can get an address from a subnet without a specified service type. This fallback ensures that legacy behavior is always preserved and there are no surprises when you upgrade.
[1] http://lists.openstack.org/pipermail/openstack-operators/2016-February/009551.html
We talked about this during the mid-cycle.
My recommendation would be to handle this with a spec. The objective here is to expose a mechanism that allows to hand-pick which IPs to consume from a router:external network.