Difference between revisions of "Neutron/LBaaS/HavanaPlan"

Revision as of 15:21, 20 May 2013

1. Integration with service type framework

- amend LBaaS extension and DB model to work with service type parameter (VIP, pool)
- integrate service types with LBaaS plugin to use service types in (2)
- client support for service types

Related blueprints:
https://blueprints.launchpad.net/quantum/+spec/service-type-framework-cleanup
https://blueprints.launchpad.net/quantum/+spec/lbaas-integration-with-service-types
Planned delivery: Havana-2.

Deliverables:

• New API for fetching service providers (service type framework)
• New workflow for the client to specify service provider when creating a pool.
• Corresponding changes in quantumclient and Horizon

2. Driver Framework for LBaaS plugin.

Blueprint: https://blueprints.launchpad.net/quantum/+spec/multi-vendor-support-for-lbaas
Planned delivery: Havana-1.
Deliverables:

• Interface for plugin-side drivers
• Infrastructure to load plugin-side drivers and dispatch calls to a proper driver

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. Drivers are selected using default service_type or type which is provided in request (see (1))

For more detail, see LBaaS/PluginDrivers

3. Improve object monitoring
Improve DB plugin and agents by adding PENDING_DELETE and ensuring that any object passes all necessary states during its lifetime.

4. Device Inventory component.
Blueprint: https://blueprints.launchpad.net/quantum/+spec/device-inventory-management
Deliverables:

• Component responsible for adding appliances to the database: API extension, object model, CLI inteface

Planned delivery: Havana-2.

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.

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

These are core features that are needed to make LBaaS production ready.

Other additional features (aside from vendor drivers) may include:

1. Agent scheduling support for reference implementation.
Improves reference implementation to allow scheduling similarly to DHCP

Blueprint: https://blueprints.launchpad.net/quantum/+spec/lbaas-agent-scheduler

2. HAProxy on VM
That may require additional generic library on top of nova client that allows managing vitual appliance lifecycle.

3. Capability-aware client or UI
Provide API for client and UI to list options supported by the given driver or service type.