[RFE] [IPAM] Make IPAM driver a per-network option

This looks like it needs an RFE.

Discussed today in the drivers meeting today. We're wondering about the demand for this. Is this just an intellectual exercise or is there much motivation to do this? The way the description is worded makes it sound like it is something to do just because it is the next logical step.

Could you build a little bit more concrete case for why should take on this work?

Full log:

http://eavesdrop.openstack.org/meetings/neutron_drivers/2016/neutron_drivers.2016-02-18-22.01.log.html#l-187

Carl, thanks for the putting this so clearly. My main concern is with justifying the extra layer of complexity

The primary use case here is for those situations in which only a subset of the networks really need to be managed in the external IPAM system. For example:

1. Use the reference driver for tenant networks but use an alternate external IPAM for external and provider networks.

2. Use the reference driver for dev/test tenants but use an alternate external IPAM production tenants.

3. Networks bridged with the L2 gateway functionality would use external IPAM but purely internal OpenStack networks would not.

Another use case is to enable the use of different configurations of the same driver. For example, we have customers with multiple instances of our IPAM systems - for example, Retail and Corporate. If the same Neutron instance is used, they would need to point at different instances of the system via different driver configurations. This one we can handle in the driver-specific way in our configs. However, by implementing this feature, we would enable similar functionality across drivers rather than individual drivers needing to implement it.

John

Just read the meeting log. Kevin suggests (I think seriously?) that each tenant brings their own IPAM. That is also a possibility - it could be done that way instead of subnet pools. Or it could even be a per-network option. Or per address space now that we have them. I don't think it's critical which of these objects we associate it with - users will just have to adjust in order to make use of the feature. Subnet pools were the original suggestion but I am open to other ideas.

I actually thing tenant, er, project makes sense since it is about the administrative domains.

With all of these options, we also need to be able to associate driver configuration at runtime.

This bug is > 180 days without activity. We are unsetting assignee and milestone and setting status to Incomplete in order to allow its expiry in 60 days.

If the bug is still valid, then update the bug status.

This is still a valid use case. In particular I am seeing a need for a per-network IPAM driver. This would allow the use of an centralized IPAM service for routable provider networks while still using standard OpenStack builtin IPAM for private tenant networks.

Let's see if, priority-wise we can put it in the backlog. Due to the complexity of the effort. I suspect this requires a full blown spec.

One concern that was raised during today's drivers meeting is the lack of resources that may be required for this effort, however, everyone was on board with the use case at this point. If you want to put together a spec to outline the proposed change you have the go-ahead.

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

One week without feedback. Let's wait to see if the author comes back, otherwise we'll have to recycle.

Hi Armando. I should be getting resources in a few weeks to work on this. I don't have the cycles myself right now.

John?

I finally have someone starting on Monday, but he'll need to ramp up. Nonetheless, I think this can be done in a few ways, some easier than others. I am inclined to go with the simplest way:

* A named entry in the config that defines an IPAM driver along with its config. For example, you can define in the config multiple instances of the same driver with different configs, and name those configs.

* An "IPAM Driver" field on the network model, that will contain one of those named configs. Only settable by the admin.

That should cover the majority of use cases - certainly the primary one described above (centralized IPAM for external and provider networks, default IPAM for private networks).

Still nothing...

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