No port create notifications received for DHCP subnet creation nor router interface attach

Bug #1560221 reported by Steve McLellan
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenStack Searchlight
New
Medium
Unassigned
neutron
Won't Fix
Undecided
Unassigned

Bug Description

Creating a subnet with DHCP enabled either creates or updates a port with device_owner network:dhcp matching the network id to which the subnet belongs. While there is a notification received for the subnet creation, the port creation or update is implicit and has not necessarily taken place when the subnet creation event is received (and similarly we don't get a notification that the port has changed or been deleted when the subnet has DHCP disabled).

My specific use case is that we're trying to index resource create/update/delete events for searchlight and we cannot track the network DHCP ports in the same way as we can ports created explicitly or as part of nova instance boots.

The same problem exists for router interface:attach events, though with a difference that we do at least get a notification indicating the port id created. It would be nice if the ports created when attaching a router to a network also sent port.create notifications.

Tested under mitaka RC-1 (or very close to) with 'messaging' as the notification driver.

Steve McLellan (sjmc7)
Changed in searchlight:
importance: Undecided → Medium
SHI Peiqi (uestc-shi)
Changed in searchlight:
assignee: nobody → SHI Peiqi (uestc-shi)
Changed in neutron:
assignee: nobody → SHI Peiqi (uestc-shi)
SHI Peiqi (uestc-shi)
Changed in searchlight:
assignee: SHI Peiqi (uestc-shi) → nobody
Changed in neutron:
assignee: SHI Peiqi (uestc-shi) → nobody
Revision history for this message
Armando Migliaccio (armando-migliaccio) wrote :

Can you tell us a little bit the messages you consume? As far I can tell the 'public' notifications are emitted for Create/Delete/Update operations (see [1,2,3] for pointers on create). If you are watching notifications like [4,5], it's probably wiser that you don't as these are not considered part of a stable interface and may be subject to change without notice (even if they haven't for ages)!

[1] https://github.com/openstack/neutron/blob/master/neutron/api/v2/base.py#L80
[2] https://github.com/openstack/neutron/blob/master/neutron/api/v2/base.py#L409
[3] https://github.com/openstack/neutron/blob/master/neutron/api/v2/base.py#L472
[4] https://github.com/openstack/neutron/blob/master/neutron/api/rpc/agentnotifiers/dhcp_rpc_agent_api.py#L124
[5] https://github.com/openstack/neutron/blob/master/neutron/api/rpc/agentnotifiers/l3_rpc_agent_api.py#L115

Changed in neutron:
status: New → Incomplete
Revision history for this message
Steve McLellan (sjmc7) wrote :

Hi Armando,

We are using the 'public' notifications, not the RPC ones.

We were seeing notifications for almost all port creation operations except for the ports created as a result of enabling DHCP on subnets. I will retest with current master; the version I was using was a month or so old now. I'll post full repro steps.

Revision history for this message
Steve McLellan (sjmc7) wrote :
Download full text (4.0 KiB)

Fresh devstack:

  $ neutron net-list -c id -c name
  +--------------------------------------+---------+
  | id | name |
  +--------------------------------------+---------+
  | 5f7774a3-759f-4798-92f0-5ef59c88705c | public |
  | abf3a939-4daf-4d05-8395-3ec735aa89fc | private |
  +--------------------------------------+---------+

  $ neutron port-list -c id
  +--------------------------------------+
  | id |
  +--------------------------------------+
  | 178db2ae-4156-4f08-8039-616b1b468240 |
  | 2d3f0bf5-4016-44b4-8238-b625c9bbd144 |
  | 455de694-3300-4ea5-be8d-d4a83ee4b6fc |
  | a68e13f2-636a-4702-a852-75861ba30b67 |
  +--------------------------------------+

  $ neutron port-show 2d3f0bf5-4016-44b4-8238-b625c9bbd144
  +-----------------------+-------------------------------------------------------------------------------------------------------------+
  | Field | Value |
  +-----------------------+-------------------------------------------------------------------------------------------------------------+
  | device_id | dhcp83063e5d-204f-5aff-a691-b0a3ac71908e-abf3a939-4daf-4d05-8395-3ec735aa89fc |
  | device_owner | network:dhcp |
  | fixed_ips | {"subnet_id": "9b6094de-18cb-46e1-8d51-e303ff844c86", "ip_address": "172.40.0.2"} |
  | | {"subnet_id": "7b7bdf5f-8f22-44a3-bec3-1daa78df83c5", "ip_address": "fd50:4918:becb:0:f816:3eff:fe27:b279"} |
  | id | 2d3f0bf5-4016-44b4-8238-b625c9bbd144 |
  +-----------------------+-------------------------------------------------------------------------------------------------------------+

Port 2d3f0bf5-4016-44b4-8238-b625c9bbd144 is the DHCP port for the 'private' network; if I create a new subnet there'll be a change made to the port but no notification of the event. Similarly if this was a new network that had no DHCP port I wouldn't get a create event.

  $ neutron subnet-create private 172.45.0.0/24 --name dhcp-enabled --enable-dhcp

  | id | face0b47-40d3-45c0-9b62-5f05311710f5 |
  | cidr | 172.45.0.0/24 |

  $ neutron port-show 2d3f0bf5-4016-44b4-8238-b625c9bbd144
  +-----------------------+-------------------------------------------------------------------------------------------------------------+
  | Field | Value |
  +-----------------------+-------------------------------------------------------------------------------------------------------------+
  | device_id | dhcp83063e5d-204f-5aff-a691-b0a3ac71908e-abf3a939-4daf-4d05-8395-3ec735aa89fc |
  | device_owner | network:...

Read more...

Revision history for this message
Steve McLellan (sjmc7) wrote :

Anyone else available to look at this at least to verify the behavior in case i've got something misconfigured? Even with a recent clone I still only see subnet.create events, no notifications for the port update/create that goes along with enabling DHCP.

Revision history for this message
li cheng (licheng185408) wrote :

Waiting for solution.

Revision history for this message
Rodolfo Alonso (rodolfo-alonso-hernandez) wrote :

Bug closed due to lack of activity, please feel free to reopen if needed.

Changed in neutron:
status: Incomplete → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.