Neutron/LBaaS/LoadbalancerInstance/Discussion

This page is going to track the discussion about LB instance.

Several approaches to the object model are presented on the pictures.
HealthMonitors as well as other entities are omitted in favor of focusing on vip-pool-instance relationship and workflow.

1. Existing model and L7 rules

L7 rules addition to existing model should allow configuring multiple pools per single vip.
Currently it's not possible to attach a pool to an existing VIP via L7 rules due to reasons:

• pool can be created with a different provider/flavor
• pool is scheduled to a device/agent/router upon creation.

So (1) and (2) mean that by default the pool doesn't reside in the same logical configuration (instance) as the VIP.

2. Loadbalancer instance solution

The above problem of colocating different objects (pools, vips) is addressed
by introducing the notion of service instance - 'Loadbalancer'; pools and vips are created with loadbalancer_id attribute
which identifies them as belonging to the same logical configuration (instance).
The backward compatibility (pool-centric) is preserved by autocreating loadbalancer object for the pool, if loadbalancer_id is not provided. Obviously this approach allows multiple pools and multiple vips within one logical configuration.

3. VIP-centric solution

The approach is mostly similar to (2) where the VIP object effectively becomes an 'instance', should be created first.
Existing notion of the VIP is an object with ip address, tcp port, session persistence and ssl attributes is delegated to a 'Listener' object
The downside of this approach is that main resources are renamed which breaks the API in backward incompatible way,
requires complex migration of existing configurations, and the terminology might be confusing.