Latest revision as of 15:54, 21 June 2013

Scope

This document describes how the particular VIP is provisioned to load-balancing device. There can be several options of doing this with full-automation on one hand and manual mode on the other. The proposal relies on minor extension to Tenant API.

Use Cases

Auto mode

This scenario is suitable for user who need just load balancing and don't have any preference on what will be behind scene.

• `Req`: There are some load-balancing devices registered in LBaaS, they may be shared or dedicated to a particular tenant.
• User creates VIP, pool, specifies health monitoring or session persistence parameters.
• LBaaS filters devices according to their capabilities and deploys VIP to one of them.
• Any change of parameter (like balancing algorithm) may result in re-deploying VIP to another device, however this procedure runs transparently for user.
• If user asks for a combination of parameters that don't fit into any available device, the error is returned.

Semi-manual mode

This scenario is suitable for users who have load balancers of different types and want more precise control over deployment.

• `Req`: There are some load-balancing devices registered in LBaaS, they may be shared or dedicated to particular tenant.
• User creates VIP and specifies set of requirements for it. This may be specific health monitoring option or performance numbers (like number of connections)
• LBaaS deploys VIP to one of suitable devices. If device is not found an error is returned.

Manual mode

This scenario is suitable for users who have stages (development, QA, production) and want to control what device is responsible for balancing.

• `Req`: There are some load-balancing devices registered in LBaaS, they may be shared or dedicated to particular tenant.
• User lists available devices.
• User creates VIP and specifies device_id.
• LBaaS deploys VIP to the specified device.
• If any unsupported option is requested LBaaS returns error.

(!) Need to extend REST API with command 'get list of devices (tenant_id)'.

Implementation Overview

The feature should be implemented as scheduler, the algorithm may be following:

• Make a list of devices available for current tenant
• Make a filter:
  • for auto mode - transparent filter
  • for semi-manual mode - filter that accepts capabilities provided by user
  • for manual mode - filter that accepts device_id
• Run filter over a list of devices
  • pick-up some device from the list and bind VIP to it
  • if no devices found, throw an exception

Data Model Changes

None

Configuration variables

None

APIs

None, but requires an extension to LBaaS Tenant API.

Plugin Interface

N/A

Required Plugin support

N/A

Dependencies

LBaaS core, LBaaS Tenant API

CLI Requirements

None

Horizon Requirements

None

Usage Example

N/A

Test Cases

N/A