Difference between revisions of "Neutron/LBaaS/LoadbalancerInstance"
(→Load balancer instance.) |
|||
| Line 8: | Line 8: | ||
# 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 | # 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 | ||
# Loadbalancer can be used to bind configuration to a provider, device, agent (host), router | # Loadbalancer can be used to bind configuration to a provider, device, agent (host), router | ||
| + | |||
==== API change ==== | ==== API change ==== | ||
| Line 13: | Line 14: | ||
VIP, Pool, Member, HealthmonitorAssociation will get loadbalancer_id attribute that could be provided (on POST) for Pool only.<br/> | VIP, Pool, Member, HealthmonitorAssociation will get loadbalancer_id attribute that could be provided (on POST) for Pool only.<br/> | ||
For VIP, Member and HealthmonitorAssociation loadbalancer_id will be deduced from related Pool object.<br/> | For VIP, Member and HealthmonitorAssociation loadbalancer_id will be deduced from related Pool object.<br/> | ||
| + | |||
==== Data model change ==== | ==== Data model change ==== | ||
| Line 23: | Line 25: | ||
* Name - String(255) | * Name - String(255) | ||
| − | Proposed change to VIP, Pool, Member objects is to add loadbalancer_id to each of them. | + | Proposed change to VIP, Pool, Member objects is to add loadbalancer_id to each of them.<br/> |
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.<br/> | 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.<br/> | ||
The same goes for VIP. Currently loadbalancer_id could be reached through pool, but moving to m:n relationship will complicate the process.<br/><br/> | The same goes for VIP. Currently loadbalancer_id could be reached through pool, but moving to m:n relationship will complicate the process.<br/><br/> | ||
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. <br/> | 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. <br/> | ||
| + | |||
==== DB Migration ==== | ==== 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. | 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<br/> | ||
| + | - db models and logic change<br/> | ||
| + | - plugin change (dispatching via loadbalancer instead of pool)<br/> | ||
| + | * python-neutronclient | ||
| + | * horizon | ||
Revision as of 13:14, 15 November 2013
Contents
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:
- 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
- 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).
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.
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
