Merge "Queue Consumer Specification"
This commit is contained in:
Jenkins
Gerrit Code Review
commit
c9d74f34bc
@ -24,7 +24,7 @@ digraph G {
|
||||
label = "Controller";
|
||||
|
||||
|
||||
apim [label="API\nManager", fontcolor=white, color=forestgreen, style=filled];
|
||||
queue [label="Queue\nConsumer", fontcolor=white, color=forestgreen, style=filled];
|
||||
health [label="Health\nManager", fontcolor=white, color=forestgreen, style=filled];
|
||||
house [label="Housekeeping\n(Spares/Cleanup)\nManager", fontcolor=white, color=forestgreen, style=filled];
|
||||
deploy [label="Deploy\nWorker", fontcolor=white, color=forestgreen, style=filled, shape=hexagon];
|
||||
@ -61,10 +61,10 @@ digraph G {
|
||||
amp [label="Amphorae", fontcolor=black, color=coral2, style=filled];
|
||||
|
||||
|
||||
deploy -> apim [dir="both"];
|
||||
db -> api -> oslo -> apim [dir="both"];
|
||||
deploy -> queue [dir="both"];
|
||||
db -> api -> oslo -> queue [dir="both"];
|
||||
db -> deploy [dir="both"];
|
||||
db -> apim [dir="both"];
|
||||
db -> queue [dir="both"];
|
||||
db -> health [dir="both"];
|
||||
db -> house [dir="both"];
|
||||
db -> msg [dir="both"];
|
||||
|
||||
@ -4,9 +4,9 @@
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
==========================================
|
||||
==================
|
||||
Octavia Controller
|
||||
==========================================
|
||||
==================
|
||||
|
||||
Launchpad blueprint:
|
||||
|
||||
@ -47,7 +47,7 @@ Proposed change
|
||||
The Octavia controller will consist of the following components:
|
||||
|
||||
* Amphora Driver
|
||||
* API Manager
|
||||
* Queue Consumer
|
||||
* Certificate Library
|
||||
* Compute Driver
|
||||
* Deploy Worker
|
||||
@ -79,14 +79,14 @@ The Amphora driver abstracts the backend implementation of an Amphora. The
|
||||
controller will interact with Amphora via the Amphora driver. This interface
|
||||
is defined in the amphora-driver-interface specification.
|
||||
|
||||
**API Manager**
|
||||
**Queue Consumer**
|
||||
|
||||
The API Manager is event driven and tasked with servicing requests from the
|
||||
The Queue Consumer is event driven and tasked with servicing requests from the
|
||||
API components via an Oslo messaging. It is also the primary lifecycle
|
||||
management component for Amphora.
|
||||
|
||||
To service requests the API Manager will spawn a Deploy Worker process.
|
||||
Spawning a seperate process makes sure that the API Manager can continue to
|
||||
To service requests the Queue Consumer will spawn a Deploy Worker process.
|
||||
Spawning a separate process makes sure that the Queue Consumer can continue to
|
||||
service API requests while the longer running deployment process is
|
||||
progressing.
|
||||
|
||||
@ -105,7 +105,7 @@ machine, container, appliance, or device that the Amphora will run in.
|
||||
|
||||
**Deploy Worker**
|
||||
|
||||
The Deploy Worker is spawned from the API Manager or the Health
|
||||
The Deploy Worker is spawned from the Queue Consumer or the Health
|
||||
Manager. It interfaces with the compute driver (in some deployment scenarios),
|
||||
network driver, and Amphora driver to activate Amphora instances,
|
||||
load balancers, and listeners.
|
||||
@ -122,7 +122,7 @@ This determination will be made based on the apolocation requirements of
|
||||
the load balancer, the load balancer count on the existing Amphora, and
|
||||
the availability of ready spare Amphora in the spares pool.
|
||||
|
||||
The Deploy Worker will be resposible for passing in the required metadata
|
||||
The Deploy Worker will be responsible for passing in the required metadata
|
||||
via config drive when deploying an Amphora. This metadata will include:
|
||||
a list of controller IP addresses, controller certificate authority
|
||||
certificate, and the Amphora certificate and key file.
|
||||
@ -132,7 +132,7 @@ amphora-lifecycle-management specification as the Activate Amphora sequence.
|
||||
|
||||
**Certificate Library**
|
||||
|
||||
The Certificate Library provides an abstration for workers to access security
|
||||
The Certificate Library provides an abstraction for workers to access security
|
||||
data stored in OpenStack Barbican from the Amphora Driver. It will provide a
|
||||
short term (1 minute) cache of the security contents to facilitate the
|
||||
efficient startup of a large number of listeners sharing security content.
|
||||
|
||||
188
specs/version0.5/queue-consumer.rst
Normal file
188
specs/version0.5/queue-consumer.rst
Normal file
@ -0,0 +1,188 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
==============
|
||||
Queue Consumer
|
||||
==============
|
||||
https://blueprints.launchpad.net/octavia/+spec/queue-consumer
|
||||
|
||||
This blueprint describes how Oslo messages are consumed, processed and
|
||||
delegated from the API-controller queue to the deploy worker component of
|
||||
Octavia. The component that is responsible for these activities is called the
|
||||
Queue Consumer.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
Oslo messages need to be consumed by the controller and delegated to the proper
|
||||
deploy worker. Something needs to interface with the API-controller queue and
|
||||
spawn the deploy workers. That "something" is what we are calling the Queue
|
||||
Consumer.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
The major component of the Queue Consumer will be be a class that acts as a
|
||||
consumer to Oslo messages. It will be responsible for configuring and starting
|
||||
a server that is then able to receive messages. There will be a one-to-one
|
||||
mapping between API methods and consumer methods (see code snippet below).
|
||||
Corresponding deploy workers will be spawned depending on which consumer
|
||||
methods are called.
|
||||
|
||||
The threading will be handled by Oslo messaging using the 'eventlet' executor.
|
||||
Using the 'eventlet' executor will allow for message throttling and removes
|
||||
the need for the deploy workers to manage threads. The benefit of using the
|
||||
'eventlet' executor is that the Queue Consumer will not have to spawn threads
|
||||
at all, since every message received will be in its own thread already. This
|
||||
means that the Queue Consumer doesn't spawn a deploy worker, rather it just
|
||||
starts the execution of the deploy code.
|
||||
|
||||
An 'oslo_messaging' configuration section will need to be added to octavia.conf
|
||||
for Oslo messaging options. For the Queue Consumer, the 'rpc_thread_pool_size'
|
||||
config option will need to be added. This option will determine how many
|
||||
consumer threads will be able to read from the queue at any given time (per
|
||||
consumer instance) and serve as a throttling mechanism for message consumption.
|
||||
For example, if 'rpc_thread_pool_size' is set to 1 thread then only one deploy
|
||||
worker will be able to conduct work. When that deploy worker completes its
|
||||
task then a new message can be consumed and a new deploy worker flow started.
|
||||
|
||||
Below are the planned interface methods for the queue consumer. The Queue
|
||||
Consumer will be listening on the **OCTAVIA_PROV** (short for octavia
|
||||
provisioning) topic. The *context* parameter will be supplied along with an
|
||||
identifier such as a load balancer id, listener id, etc. relevant to the
|
||||
particular interface method. The *context* parameter is a dictionary and is
|
||||
reserved for metadata. For example, the Neutron LBaaS agent leverages this
|
||||
parameter to send additional request information. Additionally, update methods
|
||||
include a *\*_updates* parameter than includes the changes that need to be
|
||||
made. Thus, the deploy workers responsible for the update actions will need to
|
||||
query the database to retrieve the old state and combine it with the updates to
|
||||
provision appropriately. If a rollback or exception occur, then the deploy
|
||||
worker will only need to update the provisioning status to **ERROR** and will
|
||||
not need to worry about making database changes to attributes of the object
|
||||
being updated.
|
||||
|
||||
.. code:: python
|
||||
|
||||
def create_load_balancer(self, context, load_balancer_id):
|
||||
pass
|
||||
|
||||
def update_load_balancer(self, context, load_balancer_updates,
|
||||
load_balancer_id):
|
||||
pass
|
||||
|
||||
def delete_load_balancer(self, context, load_balancer_id):
|
||||
pass
|
||||
|
||||
def create_listener(self, context, listener_id):
|
||||
pass
|
||||
|
||||
def update_listener(self, context, listener_updates, listener_id):
|
||||
pass
|
||||
|
||||
def delete_listener(self, context, listener_id):
|
||||
pass
|
||||
|
||||
def create_pool(self, context, pool_id):
|
||||
pass
|
||||
|
||||
def update_pool(self, context, pool_updates, pool_id):
|
||||
pass
|
||||
|
||||
def delete_pool(self, context, pool_id):
|
||||
pass
|
||||
|
||||
def create_health_monitor(self, context, health_monitor_id):
|
||||
pass
|
||||
|
||||
def update_health_monitor(self, context, health_monitor_updates,
|
||||
health_monitor_id):
|
||||
pass
|
||||
|
||||
def delete_health_monitor(self, context, health_monitor_id):
|
||||
pass
|
||||
|
||||
def create_member(self, context, member_id):
|
||||
pass
|
||||
|
||||
def update_member(self, context, member_updates, member_id):
|
||||
pass
|
||||
|
||||
def delete_member(self, context, member_id):
|
||||
pass
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
There are a variety of ways to consume from Oslo messaging. For example,
|
||||
instead of having a single consumer on the controller we could have multiple
|
||||
consumers (i.e. one for CREATE messages, one for UPDATE messages, etc.).
|
||||
However, since we merely need something to pass messages off to deploy workers
|
||||
other options are overkill.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
While there is no direct data model impact it is worth noting that the API
|
||||
will not be persisting updates to the database. Rather, delta updates will pass
|
||||
from the user all the way to the deploy worker. Thus, when the deploy worker
|
||||
successfully completes the prescribed action, only then will it persist the
|
||||
updates to the database. No API changes are necessary for create and update
|
||||
actions.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
None
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
None
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
None
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
None
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
The only performance related item is queue throttling. This is done by design
|
||||
so that operators can safely throttle incoming messages dependent on their
|
||||
specific needs.
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
Configuration options will need to be added to ocativa.conf. Please see above
|
||||
for more details.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
None
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
jorge-miramontes
|
||||
|
||||
Work Items
|
||||
----------
|
||||
- Implement consumer class
|
||||
- Add executable queue-consumer.py to bin directory
|
||||
|
||||
Dependencies
|
||||
============
|
||||
https://blueprints.launchpad.net/octavia/+spec/deploy-worker
|
||||
|
||||
Testing
|
||||
=======
|
||||
Unit tests
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
None
|
||||
|
||||
References
|
||||
==========
|
||||
None
|
||||
Loading…
x
Reference in New Issue
Block a user