yahoo-eng-team team mailing list archive

[OpenStack Infra <1478100@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/205631
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=0267c6a5acdcb68ea7e83ecb980362c4235ed1d7
Submitter: Jenkins
Branch:    master

commit 0267c6a5acdcb68ea7e83ecb980362c4235ed1d7
Author: Assaf Muller <amuller@xxxxxxxxxx>
Date:   Thu Jul 23 18:14:35 2015 -0400

    Make DHCP agent scheduler physical_network aware
    
    Currently neutron DCHP scheduler assumes that that every server running
    a dhcp-agent can reach every network. Typically the scheduler can
    wrongly schedule a vlan network on a dhcp-agent that has no reachability
    to the network it's supposed to serve (ex: network's physical_network
    not supported).
    
    Typically such usecase can append if:
    
    * physical_networks are dedicated to a specific service and we don't
      want to mix dnsmasqs related to different services (for
      isolation/configuration purpose),
    * physical_networks are dedicated to a specific rack (see example
      diagram http://i.imgur.com/NTBxRxk.png), the rack interconnection can
      be handled outside of neutron or inside when routed-networks will be
      supported.
    
    This change makes the DHCP scheduler network reachability aware by
    querying plugin's filter_hosts_with_network_access method.
    
    This change provides an implementation for ML2 plugin delegating host
    filtering to its mechanism drivers: it aggregates the filtering done by
    each mechanism or disables filtering if any mechanism doesn't overload
    default mechanism implementation[1] (for backward compatibility with
    out-of-tree mechanisms). Every in-tree mechanism overloads the default
    implementation: OVS/LB/SRIOV mechanisms use their agent mapping to filter
    hosts, l2pop/test/logger ones return empty set (they provide to "L2
    capability").
    
    This change provides a default implementation[2] for other plugins
    filtering nothing (for backward compatibility), they can overload it to
    provide their own implementation.
    
    Such host filtering has some limitations if a dhcp-agent is on a host
    handled by multiple l2 mechanisms with one mechanism claiming network
    reachability but not the one handling dhcp-agent ports. Indeed the
    host is able to reach the network but not dhcp-agent ports! Such
    limitation will be handled in a follow-up change using host+vif_type
    filtering.
    
    [1] neutron.plugin.ml2.driver_api.MechanismDriver.\
          filter_hosts_with_network_access
    [2] neutron.db.agents_db.AgentDbMixin.filter_hosts_with_network_access
    
    Closes-Bug: #1478100
    Co-Authored-By: Cedric Brandily <zzelle@xxxxxxxxx>
    Change-Id: I0501d47404c8adbec4bccb84ac5980e045da68b3


** Changed in: neutron
       Status: In Progress => Fix Released

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

Title:
  DHCP agent scheduler can schedule dnsmasq to an agent without
  reachability to the network its supposed to serve

Status in neutron:
  Fix Released

Bug description:
  While overlay networks are typically available on every host, flat or
  VLAN provider networks are often not. It may be the case where each
  rack only has access to a subset of networks defined in Neutron
  (Determined by the network's physical_network tag). In these cases,
  you would install a DHCP agent in every rack, but the DHCP scheduler
  could schedule a network to the wrong agent, and you end up in a
  situation where the dnsmasq instance is on the wrong rack and has no
  reachibility to its VMs.

  Here's a diagram to explain the use case:
  http://i.imgur.com/NTBxRxk.png
  Both networks on physical_network 1 should be served only by DHCP agent 1.

  More information may be found here:
  https://etherpad.openstack.org/p/Network_Segmentation_Usecases.
  Specifically "DHCP agents and metadata serices are run on nodes within each L2.  When the neutron network is created we specifically assign the dhcp agent in that segment to that network".

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