Neutron/LBaaS/LoadbalancerInstance

Description

Load balancer instance represents a container object for the load balancer configuration graph. Proposed name for this entity is 'Loadbalancer'.

Rationale

There are several reasons to introduce this object:

1. Currently the root of object graph is a pool. When we'll move to m:n vip-pool relationship, it will be much more complex to maintain and validate such configurations. Loadbalancer instance is used as an envelope to configuration graph simplifying several tasks such as binding, validation, fetching from server, REST calls dispatching
2. Loadbalancer can be used to bind configuration to a provider, device, agent (host), router

API change

New resource Loadbalancer will be introduced with attributes reflecting corresponding model (see below).
Loadbalancer will support full set of operations: create, update, delete.
VIP, Pool, Member, HealthmonitorAssociation will get loadbalancer_id attribute that could be provided (on POST) for Pool only.
For VIP, Member and HealthmonitorAssociation loadbalancer_id will be deduced from related Pool object.

Cli workflow examples:
Example 1:

lb-balancer-create --name name

lb-pool-create [--loadbalancer_id id] [usual parameters]

lb-vip-create --pool-id id

lb-balancer-show balancer_id
returns object:
---------------------------------
balancer_id id

pools: [list of pools]

vips: [list of vips]

---------------------------------

Example 2 (implicitly creating loadbalancer):
lb-pool-create [usual parameters]
lb-vip-create --pool-id id

lb-pool-show pool_id
retuns loadbalancer_id among other attributes
lb-balancer-show loadbalancer_id returns default loadbalancer object created for the pool

In other words, API is compatible with existing one yet it allows to specify multiple vips or pools for the same loadbalancer in the future.

Data model change

Adding Loadbalancer instance is one step towards changing vip-pool relationship from 1:1 to m:n, but at first we'll just introduce Loadbalancer resource to API and make corresponding changes to other objects.

Loadbalancer object:
 * id - uuid, string(36)
 * tenant_id - String(255)
 * Name - String(255)

Proposed change to VIP, Pool, Member objects is to add loadbalancer_id to each of them.
Even thought member is related to the certain pool which is related to a balancer, it might save a db query when working with member, so such data duplication might be justified.
The same goes for VIP. Currently loadbalancer_id could be reached through pool, but moving to m:n relationship will complicate the process.

In other words, REST call dispatching (e.g. choosing appropriate driver to process an object) will be handled via Loadbalancer object and not with pool.

DB Migration

In addition to simple migration for VIP, Pool, Member models, a Loadbalancer object should be created for each of existing pools and corresponding objects should be linked to this instance.

Implementation Plan

• neutron-server change

- lbaas extension change
- db models and logic change
- plugin change (dispatching via loadbalancer instead of pool)

• python-neutronclient
• horizon