yahoo-eng-team team mailing list archive

[Han Zhou <zhouhan@xxxxxxxxx>]

Public bug reported:

While routed networks [1] provides us the capability of managing L2
segments and related subnets with a view of L3 network, it assumes that
the related infrastructure resources are always provisioned (vlans,
host-segment bindings, subnets) beforehand and is not managed by
neutron. However, in a large deployment cloud, there are use cases for
on-demand resource provisioning.

- On-demand segment provisioning:

A host can be multi-tenancy, so when a host is provisioned, it may be
unknown which tenant's VMs will be scheduled to the host. So some
segments may not be needed for the host. It will be good if we can
dynamically create the segment (i.e. create the vlan on the ToR) when
the first VM of the tenant is scheduled under the ToR, then we don't
need to pre-allocate all the possible vlans and create segments for all
the ToRs.

The information that is known duiring host onboarding is the ToR that
the host is located. So we can model this as a BridgeGroup object (a
group of vlans/l2 segments spanning across the same set of hosts, which
are usually connected to a group of devices, and number of devices are
usually 1, e.g. the ToR connecting the hosts under a rack), and
BridgeGroup-Host mapping. And when the first neutron port is requested
to be created on a routed network for a host under a BridgeGroup, a new
segment is created and bound to the host.

- On-demand subnet provisioning:

In a shared infrastructure the workload location is flexible, so it is
hard to predict the number of IPs required for a segment. To use IP
resource (especially IPv4) efficiently, it will be good to be able to
dynamically allocate subnets to a segment only when it is needed, i.e.
when there are workloads scheduled to the segment.

This feature request requires [1] but put additional requirements on top
of it.

[1] https://review.openstack.org/#/c/225384/

** Affects: neutron
     Importance: Undecided
         Status: New


** Tags: 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/1577913

Title:
  [RFE] On-demand segment and subnet allocation

Status in neutron:
  New

Bug description:
  While routed networks [1] provides us the capability of managing L2
  segments and related subnets with a view of L3 network, it assumes
  that the related infrastructure resources are always provisioned
  (vlans, host-segment bindings, subnets) beforehand and is not managed
  by neutron. However, in a large deployment cloud, there are use cases
  for on-demand resource provisioning.

  - On-demand segment provisioning:

  A host can be multi-tenancy, so when a host is provisioned, it may be
  unknown which tenant's VMs will be scheduled to the host. So some
  segments may not be needed for the host. It will be good if we can
  dynamically create the segment (i.e. create the vlan on the ToR) when
  the first VM of the tenant is scheduled under the ToR, then we don't
  need to pre-allocate all the possible vlans and create segments for
  all the ToRs.

  The information that is known duiring host onboarding is the ToR that
  the host is located. So we can model this as a BridgeGroup object (a
  group of vlans/l2 segments spanning across the same set of hosts,
  which are usually connected to a group of devices, and number of
  devices are usually 1, e.g. the ToR connecting the hosts under a
  rack), and BridgeGroup-Host mapping. And when the first neutron port
  is requested to be created on a routed network for a host under a
  BridgeGroup, a new segment is created and bound to the host.

  - On-demand subnet provisioning:

  In a shared infrastructure the workload location is flexible, so it is
  hard to predict the number of IPs required for a segment. To use IP
  resource (especially IPv4) efficiently, it will be good to be able to
  dynamically allocate subnets to a segment only when it is needed, i.e.
  when there are workloads scheduled to the segment.

  This feature request requires [1] but put additional requirements on
  top of it.

  [1] https://review.openstack.org/#/c/225384/

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