openstack/barbican
Code Issues Proposed changes
0589f7fb34
barbican/doc/source/contributor/dataflow.rst
Andreas Jaeger b86d6b5660 move documentation into the new standard layout 
This change moves existing files.
It is not meant to be the final word on how the main page looks or how the
other files are organized, but it gets everything roughly into shape. If
the barbican team wants to make changes, please do those as follow-up patches.

Note this does not touch the api directory, this one needs to be
migrated to the api-ref.

This is part of the docs migration work for Pike.

Change-Id: Ibb9d971806964ac185882272514ee9563089d69d
2017-06-30 20:12:52 +02:00

3.7 KiB
Raw Blame History

Dataflow

Bootup flow when the Barbican API service begins

This is the sequence of calls for booting up the Barbican API server:

  1. bin/barbican.sh start: Launches a WSGI service that performs a PasteDeploy process, invoking the middleware components found in barbican/api/middleware as configured in etc/barbican/barbican-api-paste. The middleware components invoke and then execute the Pecan application created via barbican/api/app.py:create_main_app(), which also defines the controllers (defined in barbican/api/controllers/) used to process requested URI routes.

Typical flow when the Barbican API executes

For synchronous calls, the following sequence is generally followed:

  1. A client sends an HTTP REST request to the Barbican API server.
  2. The WSGI server and routing invokes a method on one of the XxxxController classes in barbican/api/controllers/xxxx.py, keyed to an HTTP verb (so one of POST, GET, DELETE, or PUT).
    1. Example - GET /secrets:
      1. In barbican/api/controllers/secrets.py, the SecretController's on_get() is invoked.
      2. A SecretRepo repository class (found in barbican/model/respositories.py) is then used to retrieve the entity of interest, in this case as a Secret entity defined in barbican/model/models.py.
      3. The payload is decrypted as needed, via barbican/plugin/resources.py's get_secret() function.
      4. A response JSON is formed and returned to the client.

For asynchronous calls, the following sequence is generally followed:

  1. A client sends an HTTP REST request to the Barbican API server.
  2. The WSGI server and routing again invokes a method on one of the XxxxcController classes in barbican/api/controllers/.
  3. A remote procedure call (RPC) task is enqueue for later processing by a worker node.
    1. Example - POST /orders:
      1. In barbican/api/controllers/orders.py, the OrdersController's on_post() is invoked.
      2. The OrderRepo repository class (found in barbican/model/respositories.py) is then used to create the barbican/model/models.py's Order entity in a 'PENDING' state.
      3. The Queue API's process_type_order() method on the TaskClient class (found in barbican/queue/client.py) is invoked to send a message to the queue for asynchronous processing.
      4. A response JSON is formed and returned to the client.
  4. The Queue service receives the message sent above, invoking a corresponding method on barbican/queue/server.py's Tasks class. This method then invokes the process_and_suppress_exceptions() method on one of the barbican/tasks/resources.py's BaseTask implementors. This method can then utilize repository classes as needed to retrieve and update entities. It may also interface with third party systems via plugins`. The barbican/queue/client.py's TaskClient class above may also be invoked from a worker node for follow on asynchronous processing steps.
    1. Example - POST /orders (continued):
      1. Continuing the example above, the queue would invoke the process_type_order() method on barbican/queue/server.py's Tasks class. Note the method is named the same as the TaskClient method above by convention.
      2. This method then invokes process_and_suppress_exceptions() on the barbican/tasks/resources.py's BeginTypeOrder class. This class is responsible for processing all newly-POST-ed orders.