Multi-vendor support for LBaaS  in Havana

intro

This document deals with incremental approach for promoting multi vendor support for LBaaS in Havana. The design goal is to continue what was outlined during Grizzly which is to have a single LBaaS plugin running multi-vendor drivers selected via the Service Type semantics.

This document is focused on defining the steps needed to add “Driver” support for Havana. Later documents will address the driver selection mechanisms.

The intent is to introduce each “step” in this document as a BP and a patch.

Step#0

Create a LBaas plugin that is able to load ONE LBaaS driver based on configuration.

The plugin invokes the proper call on the driver directly.

The driver at this stage must be a-sync and responsible for returning back from the LBaaS plugin calls ASAP. We plan to address async calls to the driver api in Step#2.

Plugin behaviour:

• create/update operations : create the entry in DB and mark it under PENDING_CREATE / PENDEING_UPDATE. Invoke the driver. The driver is responsible for replacing the PENDING status with a status that reflects the operation result (ACTIVE,ERROR,etc)
• delete operation: set the entry status to PENDING_DELETE. Invoke the driver. The driver is responsible for the actual deletion on the device and deletion from DB (in case of successful deletion on the device) or setting the status as ERROR (in case we failed to delete on the device)
• get operation: the superclass of the plugin (DB) takes care of the get operations.

Note: The plugin should pass a reference of itself to the driver, so the driver will be able to invoke DB operations.

Deliveries for this step: A plugin and a “noop” driver.

Once we are done with this step every vendor will be able to implement its LBaaS driver.

Step#1

Taking the HA-Proxy reference implementation delivered for Grizzly and modify it to work as an LBaaS driver. This modified driver will keep its async nature and will invoke the “name space” driver via RPC.

Once we are done with this step we can test this capability end-to-end.

Step#2

Removing the driver responsibility for async operation.

In this step the the plugin will invoke the driver api via async mechanism.

Invocation options:

• Using Queue. Flow: The plugin is invoked, handles the the DB update and put a message in a queue that is shared between the plugin and a thread. The thread “listens” to the queue and once the a message arrives it starts to process it and activate the proper method of the driver. The driver is running in process with Quantum and is able to consume API’s that are not exposed via remote calls. Example: TBD

• Using RPC (AMQP).  Flow is the same like in the previous option but now the driver can run on a different box (“lbaas agent”)