Difference between revisions of "Neutron/LBaaS/LoadbalancerInstance/Discussion"
< Neutron | LBaaS | LoadbalancerInstance
(→1. Existing model and L7 rules) |
|||
Line 7: | Line 7: | ||
L7 rules addition to existing model should allow configuring multiple pools per single vip.<br/> | L7 rules addition to existing model should allow configuring multiple pools per single vip.<br/> | ||
− | Currently it's not possible to attach a pool to an existing VIP due to | + | Currently it's not possible to attach a pool to an existing VIP via L7 rules due to reasons:<br> |
* pool can be created with a different provider/flavor | * pool can be created with a different provider/flavor | ||
* pool is scheduled to a device/agent/router upon creation. | * 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. | So (1) and (2) mean that by default the pool doesn't reside in the same logical configuration (instance) as the VIP. | ||
[[File:LbaasExisting L7.png]] | [[File:LbaasExisting L7.png]] | ||
− | |||
==2. Loadbalancer instance solution== | ==2. Loadbalancer instance solution== |
Revision as of 10:39, 17 February 2014
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.