[RFE] Add the ability to create lb vip and member with network_id

Bug #1465758 reported by Brandon Logan
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
neutron
Fix Released
Wishlist
Doug Wiegley

Bug Description

For large deployments that use cells and provider networks, it may not make sense to only allow a user to specify the subnet in which to allocate a port because nova scheduling may not be able to allocate a port on the specified subnet. Specifying a subnet would create a conflict with that, especially when it comes to capacity management.

Allowing network_id to be specified, in addition to subnet_id, will give flexibility to deployers who only want to allow allocation by network_id.

tags: added: lbaas rfe
description: updated
Revision history for this message
Doug Wiegley (dougwig) wrote :

Assuming the new fields are optional, go for it.

Changed in neutron:
status: New → Triaged
tags: added: rfe-approved
removed: rfe
Changed in neutron:
importance: Undecided → Wishlist
Changed in neutron:
milestone: none → mitaka-1
Revision history for this message
Brandon Logan (brandon-logan) wrote :

Unless someone else is really wanting this, as the original requester for this, I don't think this is somethign that is necessary anymore. It leads down a rat hole that I am not prepared to go down. You can take it off mitaka-1 if you would like.

Revision history for this message
Armando Migliaccio (armando-migliaccio) wrote :

Ok, thanks for the feedback, much appreciated.

Changed in neutron:
milestone: mitaka-1 → none
status: Triaged → Incomplete
tags: removed: rfe-approved
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for neutron because there has been no activity for 60 days.]

Changed in neutron:
status: Incomplete → Expired
Changed in neutron:
status: Expired → Confirmed
Revision history for this message
Kris Lindgren (klindgren) wrote :

I want this functionality as well. We have hardware load balancers that have 100's if not 1000's of vips. Trying to correctly guess the initial subnet size and then not being able to grow the subnet makes this highly impractical. Allowing us to specify the network_ID to use for the load balancer creation and then the plugin choosing the subnet that has available IP's is a much better route. It also aligns to how floating ip's work in neutron.

This allows us to add subnets to the lbaas network pool dynamically and eliminates people needing to know the capacity levels on each specific subnet. It also eliminates the confusion and frustration of trying multiple times with different subnets before they get an LB that can provision. Furthermore their is no API for people to be able to get subnet capacity, so in large deployments this becomes highly impractical and frustrating.

Changed in neutron:
status: Confirmed → New
Revision history for this message
David Bingham (wwriverrat) wrote :

This might become more practical if/when network_ip_availability API releases: https://review.openstack.org/#/c/212955

The scenario might go something like this:
* Define a network for the hardware load balancers (as Kris mentioned above).
* Add and define subnets for this network as demand necessitates.
* Either refactor or craft lbaas API that takes network ID.
* Call the /v2.0/network_ip_availability/{lbaas-network-id} to get availability for our lbaas network
* Iterate the availability subnet children and choose the subnet with the greatest capacity
* Use that for the subnet_id

Doug Wiegley (dougwig)
Changed in neutron:
status: New → Triaged
milestone: none → newton-1
Doug Wiegley (dougwig)
Changed in neutron:
assignee: nobody → Doug Wiegley (dougwig)
Changed in neutron:
milestone: newton-1 → newton-2
Changed in neutron:
milestone: newton-2 → newton-3
tags: added: rfe-approved
summary: - Add the ability to create lb vip and member with network_id
+ [RFE] Add the ability to create lb vip and member with network_id
Revision history for this message
Doug Wiegley (dougwig) wrote :

Not sure why this didn't get auto-linked: https://review.openstack.org/#/c/363302/

Changed in neutron:
status: Triaged → In Progress
Changed in neutron:
milestone: newton-3 → newton-rc1
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron-lbaas (master)

Reviewed: https://review.openstack.org/363302
Committed: https://git.openstack.org/cgit/openstack/neutron-lbaas/commit/?id=4455759f4506a43d70f811a32ee60b13af6afd8d
Submitter: Jenkins
Branch: master

commit 4455759f4506a43d70f811a32ee60b13af6afd8d
Author: Cedric Shock <email address hidden>
Date: Mon Aug 29 23:46:55 2016 +0000

    Allow creating loadbalancer with network_id

    Create loadbalancer accepts either a vip_subnet_id
    or vip_network_id. If vip_network_id is provided the
    vip port is created on that network using the default
    neutron behavior. If neutron assigns multiple fixed ips,
    an ipv4 addresses is chosen as the vip in preference to
    ipv6 addresses.

    -----

    Who would use the feature?
    LBaaS users on a network with multiple subnets

    Why use the feature?
    Large deployments may have many subnets to allocate
    vip addresses. Many of these subnets might have
    no addresses remaining to allocate. Creating a
    loadbalancer by network selects a subnet with an
    available address.

    What is the exact usage for the feature?

    POST /lbaas/loadbalancers
    Host: lbaas-service.cloudX.com:8651
    Content-Type: application/json
    Accept: application/json
    X-Auth-Token:887665443383838

    {
        "loadbalancer": {
            "name": "loadbalancer1",
            "description": "simple lb",
            "tenant_id": "b7c1a69e88bf4b21a8148f787aef2081",
            "vip_network_id": "a3847aea-fa6d-45bc-9bce-03d4472d209d",
            "admin_state_up": true
        }
    }

    DocImpact: 2.0 API Create a loadbalancer attributes
    APIImpact
    Closes-Bug: #1465758
    Change-Id: I31f10581369343fde7f928ff0aeb1024eb752dc4

Changed in neutron:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron-lbaas 9.0.0.0rc1

This issue was fixed in the openstack/neutron-lbaas 9.0.0.0rc1 release candidate.

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.