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.
Contents
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.
Extending existing model
LBaaS Logical Object Model Discussion The editable document above includes the "current" model including SSL and L7 and a slightly modified proposal showing a logical model. It then adds additions for status, statistics and "Provider/Flavor" management.
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.
Important limitation of the model is that only VIPs sharing the same ip address can be created within loadbalancer instance.
IP Address is specified for the instance so all VIPs of the instance share it. In other words, they share Neutron port (which is implementation detail showed for admin only)
VIP-centric solution
VIP-centric object model is a model where VIP becomes a root of the configuration (pool_id is removed from the VIP object in favor of 'default_pool_id'?).
It should be created first and then pools should be created with vip_id. This way the colocation problem is addressed, so several pools within one backend might then be used as a destination pools for L7 rules.
However this approach doesn't address multiple VIPs in one configuration. For this purpose another entity 'Listener' is introduced.
That makes this approach mostly similar to (2) because the VIP object effectively becomes an 'instance'.
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.
APIs for proposed models
API overview of proposed models could be found here: https://etherpad.openstack.org/p/neutron-lbaas-api-proposals
