yahoo-eng-team team mailing list archive

[OpenStack Infra <1544768@xxxxxxxxxxxxxxxxxx>]

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 <john.davidge@xxxxxxxxxxxxx>
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

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

Title:
  [RFE] Differentiate between service and regular subnets

Status in neutron:
  Fix Released

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

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