yahoo-eng-team team mailing list archive

[OpenStack Infra <1695740@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/470788
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=33e48cf84db0f6b51a0f981499bbd341860b6c1c
Submitter: Jenkins
Branch:    master

commit 33e48cf84db0f6b51a0f981499bbd341860b6c1c
Author: Harald Jensas <harald.jensas@xxxxxxxxx>
Date:   Sun Jun 4 23:41:19 2017 +0200

    Do not defer allocation if fixed-ips is in the port create request.
    
    Fix a usage regression, use case #2 in Nova Neutron Routed Networks spec
    https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/neutron-routed-networks.html
    
    Currently ip allocation is always deferred if binding:host_id is not
    specified when routed networks are used. This causes initial fixed-ips
    data provided by the user to be _lost_ unless the user also specify the
    host.
    
    Since the user specified the IP or Subnet to allocate in, there is no
    reason to defer the allocation.
    
    a) It is a common pattern, especially in Heat templates to:
     1. Create a port with fixed-ips specifying a subnet.
     2. Create a server and associate the existing port.
    b) It is also common to use Neutron IPAM as a source to get VIP
       addresses for clusters on provider networks.
    
    This change enables these use cases with routed networks.
    
    DocImpact: "The Networking service defers assignment of IP addresses to
    the port until the particular compute node becomes apparent." This is no
    longer true if fixed-ips is used in the port create request.
    
    Change-Id: I86d4aafa1f8cd425cb1eeecfeaf95226d6d248b4
    Closes-Bug: #1695740


** 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/1695740

Title:
  Segments, routed-networks, IPAM only usecase regression

Status in neutron:
  Fix Released

Bug description:
  Segments, routed-networks, IPAM only usecase regression

  Code[1] will defer IP allocation if host is not specified.

  Issues:
   a) This breaks the use case where Neutron is used for IPAM only with
      routed network.
   b) A user can no longer create a port and specify a fixed IP, then later
      bind the port without loosing the fixed-ip information.

   Issue b) above is a very common pattern in Heat templates.
   It is used in Heat templates examples, ref:
     - https://github.com/openstack/heat-templates/blob/master/hot/servers_in_new_neutron_net.yaml#L77:L82
     - https://github.com/openstack/heat-templates/blob/master/hot/servers_in_existing_neutron_net.yaml#L30:L46

  Current behaviour with segments is that ip-allocation is deferred for _any_ port create. Deferring ip allocation if the host is not known does make sense. Before host is known the available segments are also not known and we need to wait until the scheduler has picked a host and nova adds binding:host_id. However...
  ... this does not make sense if the subnet or fixed-ip is specified in the port create request. In this case we should not defer allocation, the user specified exactly what they want and it is known where to allocate the IP.

  When / If this port is later bound to a host, an error will be raised
  if that host does not have the correct segments. This is essentially
  the same update scenario already covered in the code?[2]

  When creating an instance using an existing port with and IP address,
  the scheduler should take the ip-allocation data from the port
  provided in the request and ensure that the instance is scheduled to a
  host that is connected to the correct segment. According to nova
  neutron-routed-networks spec[1] this exact use case was included.

      """ Use case 2:
           User has a port that has an IP address and thus is effectively
           attached to a segment (but not bound to a host). He/She
           provides it to nova boot. Nova will ask Neutron for the segment
           to which the port is bound by getting the details of the port.
           Given that segment, the scheduler should place the instance
           on a compute host belonging to the corresponding aggregate. """

  [1] https://github.com/openstack/neutron/blob/master/neutron/db/ipam_backend_mixin.py#L662:L700
  [2] https://github.com/openstack/neutron/blob/master/neutron/db/ipam_backend_mixin.py#L769:L777
  [3] https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/neutron-routed-networks.html

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