Comment 17 for bug 1806390

Hi Slawek again,

Thanks for attention of this request.

Here is my answer what you asked.

1. IIUC Your proposal, You want to have dhcp agents deployed on all compute nodes and let specific dhcp agent to configure only ports which are on this specific compute node, am I right?
> Yes right.

How do You want e.g. do it during migration of vm? Currently DHCP agent don't need to be aware of something like that at all. But in Your case it will be additional step which needs to be done, right?
> No. In fact it does not need to have addition step for that. It's major difference of original request (https://review.opendev.org/#/c/184423/)

I found the original PR is to change agentnotifier side (which is changing default action sending all DHCP bound agents to send a specific agent). As you can see, past reviewer for the PR already warn the complexity because it's difficult to sync port-binding / agent notifying like many situations (e.g. migration..)

I agreed with the reviewer and wondered if there is another way. After that, I realized I don't have to change notifier side (just letting it send fanout to agents) with small change at the agent piggy backing API (get_active_networks_info) since major DB scale problem was caused by 'provisioning_block'.

So my point is since every distributed DHCP agents also receive fanout messages, we don't have to worry about the port-binding update timing. Distributed dhcp agent could work normally as they can receive port update event whenever port-binding updated.

2. Maybe that would be more scalable solution which You could use alternatively?
> Personally, I think OVN is one of the best scalable solution in current status. I definitely use it if we can make new clusters rather than changing existed clusters. T_T But there were several issues that we can just use it now.

First of all, we do not use Openvswitch. I can give why we prefer linuxbridge to openvswitch but it seems to be off-topic so I just omit it.

Only for 'distributed' DHCP, we don't want to rely agent-based implementation since imho Neutron has already enough features to do it. (Again this PR is just to optimize operation/performance).

Thanks!