[RFE] Differentiate between service and regular subnets

Bug #1544768 reported by Carl Baldwin on 2016-02-11
This bug affects 3 people
Affects Status Importance Assigned to Milestone
John Davidge

Bug Description

I've been thinking about this for a little while now. There seems to be something different about floating IP subnets and other (I'll call them "service" in this context) subnets in some use cases.

- On an external network where operators wish to use private IPs for router ports (and DVR FIP ports) and public for floating IPs.
- Enable using floating IPs on provider networks without routers [1]. This has come up a lot. In many cases, operators want them to be public while the static ones are private.
- On routed networks where VM instance and router ports need IPs from their segments but floating IPs can be routed more flexibly.

I don't think we need to implement all of these use cases with this RFE. I think this RFE should just solve the first one about router ports. However, all of them seem to all need some way to distinguish different subnets on the same network for different purposes.

Let's add a service type field to the subnet. To start with, we’ll have two possible values other than the current default of null: "dvr_gateway", and "dvr_and_router_ports". The names aren’t written in stone. The choice between the two depends on if you want your routers to get public addresses for SNAT. IPAM will consider the service type when allocating a port for a particular device_owner. Each device_owner will have a (possibly empty) list of service types to prefer.

Any kind of port can get an address from a subnet without a specified service type. This fallback ensures that legacy behavior is always preserved and there are no surprises when you upgrade.

[1] http://lists.openstack.org/pipermail/openstack-operators/2016-February/009551.html

Changed in neutron:
status: New → Confirmed
importance: Undecided → Wishlist
tags: added: l3-ipam-dhcp rfe
Changed in neutron:
status: Confirmed → Triaged
summary: - [RFE] Differentiate between static and floating subnets
+ [RFE] Differentiate between service and floating subnets
description: updated
Changed in neutron:
assignee: nobody → Brian Haley (brian-haley)
milestone: none → newton-1

We talked about this during the mid-cycle.

My recommendation would be to handle this with a spec. The objective here is to expose a mechanism that allows to hand-pick which IPs to consume from a router:external network.

summary: - [RFE] Differentiate between service and floating subnets
+ [RFE] Differentiate between service and regular subnets
Changed in neutron:
milestone: newton-1 → newton-2
Changed in neutron:
milestone: newton-2 → newton-3
Changed in neutron:
assignee: Brian Haley (brian-haley) → John Davidge (john-davidge)
status: Triaged → In Progress
Changed in neutron:
assignee: John Davidge (john-davidge) → Carl Baldwin (carl-baldwin)
Changed in neutron:
assignee: Carl Baldwin (carl-baldwin) → John Davidge (john-davidge)

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

commit de3a3cda740dfa22152c8224c39aeb9e51642d93
Author: John Davidge <email address hidden>
Date: Mon Aug 1 14:04:08 2016 +0100

    IP allocation with Service Subnets

    This changes the way that IPAM decides which subnets to use when
    assigning IPs to newly created ports. If the port has a defined
    device_owner, this is used to filter available subnets to choose
    from only those with a matching service_type or no service_type
    at all.

    If the given network has no service subnets, then the existing
    behaviour is used.

    A new IPAM exception is introduced to handle the following scenarios:
    1. A port is created with a device_owner and only non-matching service
       subnets exist.
    2. A port is created without a device owner, and no subnets exist
       without a service_type.

    With this patch, service subnets are now usable.

    Implements: blueprint service-subnets
    APIImpact: subnet-create and subnet-update with service_types
    DocImpact: IPs assigned to new ports will now come from a service subnet
    matching the port device_owner, if one exists.

    Closes-Bug: 1544768
    Change-Id: If3dd94a46bdee24c13d1f17c4f2e69af0cb8af63

Changed in neutron:
status: In Progress → Fix Released

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers