yahoo-eng-team team mailing list archive

[Kyle Mestery <1458890@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

This is feedback from the Vancouver OpenStack Summit.

During the large deployment team (Go Daddy, Yahoo!, NeCTAR, CERN,
Rackspace, HP, BlueBox, among others) meeting, there was a discussion of
network architectures that we use to deliver Openstack.  As we talked it
became clear that there are a number of challenges around networking.

In many cases, our data center networks are architected with a
differientation between layer 2 and layer 3.  Said another way, there
are distinct network "segments" which are only available to a subset of
compute hosts.  These topolgies are typically necessary to manage
network resource capacity (IP addresses, broadcast domain size, ARP
tables, etc.)   Network topologies like these are not possible to
describe with Neutron constructs today.

The traditional solution to this is tunneling and overlay networks which
makes all networks available everywhere in the data center.  However,
overlay networks represent a large increase in complexity that can be
very difficult to troubleshoot.  For this reason, many large deployers
are not using overlay networks at all (or only for specific use cases
like private tenant networks.)

Beacuse Neutron does not have constructs that accurately describe our
network architectures, we'd like to see the notion of a network
"segment" in Neutron.  A "segment" could mean a L2 domain, IP block
boundary, or other partition.  Operators could use this new construct to
build accurate models of network topology within Neutron, making it much
more usable.

    Example:  The typical use case is L2 segments that are restrained to
a single rack (or some subnet of compute hosts), but are still part of a
larger L3 network.  In this case, the overall Neutron network would
describe the L3 network, and the network segments would be used to
describe the L2 segments.


WIth the network segment construct (which are not intended to be exposed to end users ), there is also a need for some scheduling logic around placement and addressing of instances on an appropriate network segment based on availablity and capacity.  This also implies a means via API to report IP capacity of networks and segments, so we can filter out segments without capacity and the compute nodes that are tied to those segments.

    Example:  The end user chooses the Neutron network for their
instance, which is actually comprised of several lower level network
segments within Neutron.  Scheduling must be done such that the network
segment chosen for the instance is available to the compute node on
which the instance is placed.  Additionally, the network segment that's
chosen must have available IP capacity in order for the instance to be
placed there.


Also, the scheduling for resize, migrate, ... should only consider the compute nodes allowed in the "network segment" where the VM is placed.

** Affects: neutron
     Importance: Undecided
         Status: New


** Tags: rfe

** Tags added: rfe

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

Title:
  Add segment support to Neutron

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  This is feedback from the Vancouver OpenStack Summit.

  During the large deployment team (Go Daddy, Yahoo!, NeCTAR, CERN,
  Rackspace, HP, BlueBox, among others) meeting, there was a discussion
  of network architectures that we use to deliver Openstack.  As we
  talked it became clear that there are a number of challenges around
  networking.

  In many cases, our data center networks are architected with a
  differientation between layer 2 and layer 3.  Said another way, there
  are distinct network "segments" which are only available to a subset
  of compute hosts.  These topolgies are typically necessary to manage
  network resource capacity (IP addresses, broadcast domain size, ARP
  tables, etc.)   Network topologies like these are not possible to
  describe with Neutron constructs today.

  The traditional solution to this is tunneling and overlay networks
  which makes all networks available everywhere in the data center.
  However, overlay networks represent a large increase in complexity
  that can be very difficult to troubleshoot.  For this reason, many
  large deployers are not using overlay networks at all (or only for
  specific use cases like private tenant networks.)

  Beacuse Neutron does not have constructs that accurately describe our
  network architectures, we'd like to see the notion of a network
  "segment" in Neutron.  A "segment" could mean a L2 domain, IP block
  boundary, or other partition.  Operators could use this new construct
  to build accurate models of network topology within Neutron, making it
  much more usable.

      Example:  The typical use case is L2 segments that are restrained
  to a single rack (or some subnet of compute hosts), but are still part
  of a larger L3 network.  In this case, the overall Neutron network
  would describe the L3 network, and the network segments would be used
  to describe the L2 segments.

  
  WIth the network segment construct (which are not intended to be exposed to end users ), there is also a need for some scheduling logic around placement and addressing of instances on an appropriate network segment based on availablity and capacity.  This also implies a means via API to report IP capacity of networks and segments, so we can filter out segments without capacity and the compute nodes that are tied to those segments.

      Example:  The end user chooses the Neutron network for their
  instance, which is actually comprised of several lower level network
  segments within Neutron.  Scheduling must be done such that the
  network segment chosen for the instance is available to the compute
  node on which the instance is placed.  Additionally, the network
  segment that's chosen must have available IP capacity in order for the
  instance to be placed there.

  
  Also, the scheduling for resize, migrate, ... should only consider the compute nodes allowed in the "network segment" where the VM is placed.

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