[openstack-dev] [Neutron] Issue with neutron-dhcp-agent not recovering known ports cache after restart
Shraddha Pandhe
spandhe.openstack at gmail.com
Tue Jul 28 19:48:58 UTC 2015
Hi,
I have added few more questions to the bug [1]. Please confirm my
understanding.
[1] https://bugs.launchpad.net/neutron/+bug/1470612/comments/12
On Tue, Jul 28, 2015 at 12:14 PM, Shraddha Pandhe <
spandhe.openstack at gmail.com> wrote:
> Hi,
>
> I started working on this patch for bug [0], but it doesn't seem as
> straightforward as Kevin and I initially thought. Here's why:
>
> Initially we thought that a simple self.cache.push_port will work as
> follows:
>
> In __init__ [1], in _populate_network_cache [2], get all existing active
> networks from neutron using plugin_rpc similar to [3]. Then, for each of
> those networks, go through all the subnets and ports and add them in [4]
> before updating the cache.
>
> But I realized that this will not work because, if we try to get all
> active subnets and ports and populate those in cache, we may miss the
> delta. Consider following scenario:
>
> Cache state before agent stopped:
> networks 1
> subnets 4
> ports 10
>
> While the agent was down:
> networks 1
> subnets 6
> ports 12
>
> Now, then the agent comes back up, if we follow the above method, the
> network cache will immediately populate itself to the new state, without
> actually creating those subnets and ports in dhcp config. So if we want to
> follow this route, we need a mechanism to get known_subnet_ids and
> known_port_ids from dhcp driver, just like we get known_network_ids at [5]
> &[6]. To me, that seems too much work for what it does.
>
> Any better ideas to solve this problem?
>
>
>
> [0] https://bugs.launchpad.net/neutron/+bug/1470612
> [1]
> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L54
> [2]
> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L75
> [3]
> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L156
> [4]
> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L82-L85
> [5]
> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L78
> [6]
> https://github.com/openstack/neutron/blob/master/neutron/agent/linux/dhcp.py#L293-L302
>
> On Wed, Jul 1, 2015 at 11:28 AM, Shraddha Pandhe <
> spandhe.openstack at gmail.com> wrote:
>
>> Hi,
>>
>> I had a discussion about this with Kevin Benton on IRC. Filed a bug:
>> https://bugs.launchpad.net/neutron/+bug/1470612
>>
>> Thanks!
>>
>>
>> On Wed, Jul 1, 2015 at 11:03 AM, Shraddha Pandhe <
>> spandhe.openstack at gmail.com> wrote:
>>
>>> Hi Shihan,
>>>
>>> I think the problem is slightly different. Does your patch take care of
>>> the scenario where a port was deleted AFTER agent restart (not when agent
>>> was down)?
>>>
>>> My problem is that, when the agent restarts, it loses its previous
>>> network cache. As soon as the agent starts, as part of "__init__", it
>>> rebuilds that cache [1]. But it does not put the ports in there [2].
>>>
>>> In sync_state, Neutron tries to enable/disable networks, by checking the
>>> diff between Neutron's state and its own network cache that it just built
>>> [3]. It enables any NEW networks and disables any DELETED networks, but it
>>> does nothing to PREVIOUSLY KNOWN NETWORKS. So those subnets and ports
>>> remain empty lists.
>>>
>>> Now, if such a port is deleted, [4] will return None and the port will
>>> never get deleted from the config.
>>>
>>> [1]
>>> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L68
>>> [2]
>>> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L79-L86
>>> [3]
>>> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L154-L171
>>> [4]
>>> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L349
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150728/be59b5ef/attachment.html>
More information about the OpenStack-dev
mailing list