Include the URL of your launchpad RFE: https://blueprints.launchpad.net/dragonflow/+spec/driver-of-redis Add a DataBase support for DragonFlow
Dragonflow will use Publish/Subscribe as a method to realize communication between components. Redis DB has a good performance of Publish/Subscribe. So,We need a driver for Redis DB,meanwhile, if other DB which support Publish/Subscribe only needs overwrite new APIS added here. dragonflow will have a efficient way to realize communication between different component.
As dragonflow already has a class for DB API, here we just need to overwrite those APIs already existed, and add new APIS for the Publish/Subscribe, based on andymccurdy lib[1].
Basic operation for Redis DB,including add/delete/get/modify and so on. Realization is based on Grokzen lib. The following diagram shows which components will populate Redis DB Cluster with driver[4].:
+------------------+ +----------------+
|Neutron server | | Redis Driver |
| | func call | |
| Plugins +----------> | |
| | | |
| | | | +------------------+
| | | realize | | Redis DB Cluster |
+------------------+ | add/del/get +------> | |
| using DB API | | |
+------------------+ | | | |
| | | | +------------------+
| Compute Node | func call | |
| +----------> | |
| Applications | | |
| | | |
| | | |
+------------------+ +----------------+
The new API realizes publish function with channel, based on andymccurdy lib The following diagram shows how Neutron config changes are published to all local controllers. It is only a example.:
+---------------+
| | +-----------------+
| DF Neutron | | Redis DB |
| Plugin | | |
| | | |
| Configuration| | |
| Change | | |
| | call Publish API | |
| +----------------------------------------> | |
| | | |
| | | |
| | +-----------------+
| |
+---------------+
Main process of realization:
Special Notice: ‘Some data’ will be coded into json pattern. Above example ,subscriber which subscribes the channel ‘my-first-channel’ will receive what is published. More details please refer Publish / Subscribe section of [1]
If you want to receive message that you publish,you first should do a subscription, if you do not want to receive message,you should withdraw subscription. Realization is based on andymccurdy lib.
Here is a example of subscription process:
Here is an example of message driver may received:
channel: The channel [un]subscribed to or the channel a message was published to.
Special Notice: This message is only processed by driver. Message data will be decoded by driver and send into queue. Psubscribe,Punsubscribe and Pmessage are not used here,they are used for pattern match.[1]
The subscribe thread is in charge of receiving the notifications and sending them back to the controller. Realization is based on andymccurdy lib.
The subscribe thread loop is depicted in the following diagram:
+-----------------+ +---------------+
| | | |
| | | Process |
| | +-----------------+fun call | Function1 |
| | | +-------->| |
|Subscribe Thread | | Message Dispatch| +---------------+
| | | |
| Wait For Message| | |
| | | Read Message | +---------------+
| | Send into Queue | From Queue |fun call | Process |
| New Message +-----------------------> +-------->| Function2 |
| | | Dispatch Message| | |
| | | | +---------------+
| | | |
| | | |
| | | | +---------------+
| | | |fun call | Process |
| | | +---------> Function3 |
| | | | | |
+-----------------+ +-----------------+ | |
+---------------+
Realization Example:
Special Notice: Not only three Process Functions. Driver Subscriber thread is only one thread to do message dispatch according to channel. listen() is a generator that blocks until a message is available.
This resubscription should be done only when connection to DB server is recovered.
driver only does connection fix,throw exception when connection is recovered, driver will clear all subscription and user of Subscription do resubscribe.
When driver is initialized,it will connect to all db nodes for read/write/get/modify operation. But for pub/sub, driver will connect to one db node for one pub or one sub. Driver guarantee connections for pub/sub will be scattered among db nodes.
First Notice:exception of cluster client and single client are different, need processed separately. case1:populate db failed If add operation is failed, driver will delete what you add, driver will check connection and reconnect if reason is connection lost, driver will try several times( for example 3), if all trials failed, driver will return failed, if reason is not connection problem, driver will also return failed directly. You should return failed to up level, do not publish, if driver returned failed.
If delete operation is failed, the process is same as above, except for driver will not rollback delete operation.
case2:publish failed If this happened, driver will return failed and check connection also reconnect if reason is connection lost. If driver return failed, user of API should undo what you done before publish and return failed to up level
case3:subscribe failed If this happened, driver will return failed and check connection also reconnect if reason is connection lost. If driver return failed, user of api return failed to up level.
case4:subscribe listen exception If this happened, Driver will clear all subscription and then try reconnect, after fix connection then send a message to subscriber, tell that you subscribed is recovered, subscriber should subscribe again.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.