Jump to: navigation, search

Difference between revisions of "Neutron/LBaaS/HavanaPlan"

< Neutron‎ | LBaaS
(Created page with "'''1. Integration with service type framework''' - amend LBaaS extension and DB model to work with service type parameter (VIP, pool) - improve service type extension. '''2...")
 
Line 28: Line 28:
  
 
<gallery>
 
<gallery>
File:Example.jpg|Caption1
+
File:Havana_LBaaS_Diagram.jpg|LBaaS architecture
File:Example.jpg|Caption2
 
 
</gallery>
 
</gallery>
  

Revision as of 14:30, 25 April 2013

1. Integration with service type framework

- amend LBaaS extension and DB model to work with service type parameter (VIP, pool)
- improve service type extension.

2. Driver Framework for LBaaS plugin.

Rationale: Basic LBaaS plugin provides reasonable amount of features. However interaction with backend servers may be different for different vendors. It's not only about appliance access, but primarily about how request reaches device driver. There are several possible options here:

1) current implementation. Plugin sends notifications to agent, agent pulls configuration from the plugin.

2) "advanced reference implementation". We may want to improve reference implementation to adopt agent-scheduler approach.

3) Request proxy. After request has passed persistance layer (db plugin) it is passed to external component, which is responsible for choosing device, applying configuration, etc.

4) passive agent. Plugin performs device selection, then sends CRUD request augmented with device info to agent, where it translates the call to the driver and passes device information.

So we may create several drivers at plugin side, which will adopt these approaches. For instance, for reference implementation such driver will consist of notification sending or no-op for requests that don't send notifications.

3. Device Inventory component.

Rationale: Some vendor implementation may require storing available appliances and their parameters to choose to which instance logical configuration will be deployed. Such component could be made generic to support different kinds of service devices: loadbalancer, VPN, firewall, etc.

4. Routed insertion implementation
This is a complex generic feature that could be utilized by any service instance (appliance) that can act as a router