yahoo-eng-team team mailing list archive

[Andrew Bonney <1964765@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

We have a Xena deployment based on Linux bridge networking, with a mix
of Neutron managed VXLAN, and routed/L3 provider networks.

neutron-dhcp-agent services are deployed to a set of network nodes in
order to serve the VXLAN networks. These services are also deployed to a
subset of compute nodes which are the only hosts with access to the
routed provider networks.

We would like the network nodes to be used in preference to the compute
nodes when DHCP instances are created against VXLAN tenant networks.
Having written a patch to achieve this (modifying the DHCP scheduler
filtering -
https://github.com/bbc/neutron/commit/54b135e1412d83acb68995a71ed864118162ab01),
this works correctly when networks are first created. However, if a
given network has a DHCP agent/port removed at any point and a DHCP
service on one of the compute nodes is subsequently restarted, these
filters are ignored and the compute node takes over this responsibility.

As far as I can tell, when the DHCP agent service starts up it requests
details of the active networks and seeing a network it can reach which
doesn't have the correct number of agents deployed, takes over this
responsibility, bypassing the scheduling filters. The existing filters
which ensure a DHCP service has physical access to a given L3 segment
appear to work because there is a second implementation of that
filtering in
https://github.com/openstack/neutron/blob/master/neutron/api/rpc/handlers/dhcp_rpc.py#L212.

I'd appreciate a second opinion on whether by making changes to the DHCP
scheduler filtering only, it should be reasonable to expect its rules to
apply at times after initial network/subnet creation? If there is an
architectural reason the filters don't get re-used, would my best option
be to add further patching in dhcp_rpc to achieve the desired behaviour?
Thanks

** Affects: neutron
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1964765

Title:
  DHCP agent scheduler filtering ignored when agent service restarted

Status in neutron:
  New

Bug description:
  We have a Xena deployment based on Linux bridge networking, with a mix
  of Neutron managed VXLAN, and routed/L3 provider networks.

  neutron-dhcp-agent services are deployed to a set of network nodes in
  order to serve the VXLAN networks. These services are also deployed to
  a subset of compute nodes which are the only hosts with access to the
  routed provider networks.

  We would like the network nodes to be used in preference to the
  compute nodes when DHCP instances are created against VXLAN tenant
  networks. Having written a patch to achieve this (modifying the DHCP
  scheduler filtering -
  https://github.com/bbc/neutron/commit/54b135e1412d83acb68995a71ed864118162ab01),
  this works correctly when networks are first created. However, if a
  given network has a DHCP agent/port removed at any point and a DHCP
  service on one of the compute nodes is subsequently restarted, these
  filters are ignored and the compute node takes over this
  responsibility.

  As far as I can tell, when the DHCP agent service starts up it
  requests details of the active networks and seeing a network it can
  reach which doesn't have the correct number of agents deployed, takes
  over this responsibility, bypassing the scheduling filters. The
  existing filters which ensure a DHCP service has physical access to a
  given L3 segment appear to work because there is a second
  implementation of that filtering in
  https://github.com/openstack/neutron/blob/master/neutron/api/rpc/handlers/dhcp_rpc.py#L212.

  I'd appreciate a second opinion on whether by making changes to the
  DHCP scheduler filtering only, it should be reasonable to expect its
  rules to apply at times after initial network/subnet creation? If
  there is an architectural reason the filters don't get re-used, would
  my best option be to add further patching in dhcp_rpc to achieve the
  desired behaviour? Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1964765/+subscriptions