Updates the controller spec to clarify API Manager
Clarifying the role the API Manager will play in the Octavia version 0.5 controller. Change-Id: I1facdbc8d2059fb4dac4f3e9d195a884758ad16d
This commit is contained in:
parent
9b989e2f8a
commit
e1fd87ae4c
specs/version0.5
@ -27,7 +27,7 @@ digraph G {
|
||||
apim [label="API\nManager", 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];
|
||||
deploy [label="Deploy\nWorker", fontcolor=white, color=forestgreen, style=filled, shape=hexagon];
|
||||
proxy [label="Services\nProxy", fontcolor=white, color=forestgreen, style=filled];
|
||||
|
||||
|
||||
@ -61,6 +61,7 @@ digraph G {
|
||||
amp [label="Amphorae", fontcolor=black, color=coral2, style=filled];
|
||||
|
||||
|
||||
deploy -> apim [dir="both"];
|
||||
db -> api -> oslo -> apim [dir="both"];
|
||||
db -> deploy [dir="both"];
|
||||
db -> apim [dir="both"];
|
||||
|
@ -82,25 +82,21 @@ is defined in the amphora-driver-interface specification.
|
||||
**API Manager**
|
||||
|
||||
The API Manager is event driven and tasked with servicing requests from the
|
||||
API components via an Oslo messaging queue. It is also the primary lifecycle
|
||||
management component for Amphora. Many API requests can be serviced by
|
||||
querying the database for the current state of load balancers and listeners.
|
||||
API components via an Oslo messaging. It is also the primary lifecycle
|
||||
management component for Amphora.
|
||||
|
||||
Requests for a new load balancer or listener will cause the API Manager to
|
||||
spawn a Deploy Worker process. Spawning a seperate process makes sure that
|
||||
the API Manager can continue to service API requests while the longer running
|
||||
deployment process is progressing.
|
||||
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
|
||||
service API requests while the longer running deployment process is
|
||||
progressing.
|
||||
|
||||
API requests may also cause the API Manager to push updated configurations to
|
||||
the Octavia database and notify the driver to push an updated configuration
|
||||
to the listener. A worker will be dispatched to supervise the process of
|
||||
pushing out the new configuration.
|
||||
|
||||
Delete requests for load balancers or listeners will call the Amphora driver
|
||||
wrap up method to gracefully shutdown the processes, ship logs, ship
|
||||
statistics, un-plug network resources, and mark pending delete status in the
|
||||
database for the Housekeeping Manager to cleanup the Amphora should it no
|
||||
longer be needed.
|
||||
Messages received via Oslo messaging will include the load balancer ID,
|
||||
requested action, and configuration update data. Passing the configuration
|
||||
update data via Oslo messaging allows the deploy worker to rollback to a
|
||||
"last known good" configuration should there be a problem with the
|
||||
configuration update. The spawned worker will use this information to access
|
||||
the Octavia database to gather any additional details that may be required to
|
||||
complete the requested action.
|
||||
|
||||
**Compute Driver**
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user