Segments, routed-networks, IPAM only usecase regression

[Harald Jensås]

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

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/470788

[Bob Fournier (bfournie)]

I verified this using the following Heat snippet when using segments:
heat_template_version: ocata

description: Template to create an ironic instance

resources:
  instance_port:
    type: OS::Neutron::Port
    properties:
      network: ctlplane
      fixed_ips: [{"subnet": ctlplane-subnet, "ip_address": 10.8.146.8}]

  my_ironic_instance:
    type: OS::Nova::Server
    properties:
      key_name: default
      image: overcloud-full
      flavor: baremetal
      networks:
        - network: ctlplane
          port: {get_resource: instance_port}

The subnet is associated with a segment:
[stack@host01 ~]$ openstack network segment list
+--------------------------------+-------------------+--------------------------------+--------------+---------+
| ID | Name | Network | Network Type | Segment |
+--------------------------------+-------------------+--------------------------------+--------------+---------+
| 4ee588ef-e326-4e35-83db- | ctlplane-segment1 | 552fe717-6386-4c07-9683-e5e6c5 | flat | None |
| 3436d011e9a3 | | 1f9af1 | | |
+--------------------------------+-------------------+--------------------------------+--------------+---------+
[stack@host01 ~]$ openstack subnet show ctlplane-subnet
+-------------------+--------------------------------------------------------+
| Field | Value |
+-------------------+--------------------------------------------------------+
| allocation_pools | 10.8.146.5-10.8.146.20 |
| cidr | 10.8.146.0/24 |
| created_at | 2017-05-31T18:52:52Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 10.8.146.1 |
| host_routes | destination='169.254.169.254/32', gateway='10.8.146.1' |
| id | 41f65e44-eaa3-4563-91a4-a13597227696 |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 552fe717-6386-4c07-9683-e5e6c51f9af1 |
| project_id | 08b43a05b88c4d4089355b3aba9dd8fb |
| revision_number | 2 |
| segment_id | 4ee588ef-e326-4e35-83db-3436d011e9a3 | <==
| service_types | |
| subnetpool_id | None |
| updated_at | 2017-05-31T18:52:52Z ...

[OpenStack Infra (hudson-openstack)]

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 <email address hidden>
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

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 11.0.0.0b3 development milestone.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/ocata
Review: https://review.openstack.org/499954

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/499954
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=630b2d1a5e8b8c6926a590eb87fedde12624c3da
Submitter: Jenkins
Branch: stable/ocata

commit 630b2d1a5e8b8c6926a590eb87fedde12624c3da
Author: Harald Jensas <email address hidden>
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
    (cherry picked from commit 33e48cf84db0f6b51a0f981499bbd341860b6c1c)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 10.0.4 release.