BrokerProject

The Broker

We have this set of requirements:

• A REST API, rather than a web UI
• The ability to support launching instances, creating subnets and
  firewalls, creating attachable storage, and lifecycle management on
  all of the cloud components that a Heat template can specify
• Aggregation of multiple providers (or sub-components/realms of a
  provider's capacity) into pools
• Exposure of pools through an IaaS API (could be realized with a
  Deltacloud driver)
• Hardware profile matching
• Configurable provider selection policies.
• Account credentials multiplexing
• Permissioning users and groups
• Usage Quotas
• History

Then we have various variants that I try to put together from what has been
said and written in the mailing list.

1. Broker as an optional broker service

1. deltacloud is a lib
2. there is a stateful service (app) on top of it which implements CIMI standard
3. there is an additional and optional broker service
4. CIMI app and Broker can be both mounted as rack apps
5. broker service includes: API + DB + thin backend which overrides calls
   from CIMI app to deltacloud lib where necessary (e.g. instead of list of
   provider types it will return list of pools

Rough schema:

|Heat (or other client)|                                                      
  |                                                                         
  |                                                                         
|CIMI app|                    |broker mgmt API|                               
  |                               |                                         
  |                               |                                         
|*optional broker backend|-------|broker db|                                  
  |                                                                         
  |                                                                         
|deltacloud lib|                                                              

`
Crucial part of this suggestion is that the current DC is separated into 2
components:

• the CIMI app (statefull app that implements CIMI on top of DC)
• the DC library

There is simple abstraction layer between CIMI app and deltacloud lib, if
Broker app is not mounted/activated, then communication between CIMI app and
dc lib goes through this abstraction layer.

This clearly unwires some of the arrows from the variant 2 which we can take as an advantage of this suggestion.

Also with this approach we do not need to implement the IaaS interface 2x, it
stays only in the CIMI app.

2. Broker as a DC driver

Heat talks to DC or the broker (that is a DC driver), seen no difference
between the two.

Broker and DC are together in one process. Internally broker calls DC as a
library. From outside they form a single service.

The mgmt API that the broker needs to operate is provided in the same process
under a different prefix, does not interact with that DC has.

Rough schema:

      Head or other client                                                      
          |                                                                     
          |                                                                     
      |DC/CIMI REST API|            |broker mgmt API|                           
          |                               |                                     
 +--> |deltacloud lib|                    |                                     
 |        |     |                         |                                     
 |        |     +-------> providers       |                                     
 |        |                               |                                     
 |    |broker DC driver|                  |                                     
 |        |                               |                                     
 |        |                               |                                     
 +----|broker backend|----------------|broker db|                               

Two main adventages of this aproach are:

• whatever API DC implements for the IaaS API, broker get's it
• one less daemon

2a. Broker as a DC driver, two DCs

A variant of the 2. approach but to keep the broker out of DC we use 2 DCs one
with the driver providing just the broker functionality through DC or CIMI
interface and second to serve broker's requests towards cloud providers.

2b. Broker as a Rack app mounting DC

This variant of the 2. does not relly on cooperation of the DC team and uses
some hacks so that the broker calls in-process instance of DC even though DC
does not oficially offer a library.

3. Broker build from the sources of Conductor

Rough schema:

|Heat (or other client)|                                                      
    |                                                                         
    |                                                                         
|some IaaS api|   |broker mgmt API|                                           
    |                    |                                                    
    |                    |                                                    
|broker|-------------|broker db|                                              
    |                                                                         
    |                                                                         
|deltacloud|                                                                  

Nothing changes between Broker (Conductor) and DC, both are a separate service. Broker implements some IaaS API that Heat can call.

Advantages:

• DC can stay as it is (is it really an advantage?)
• more code reuse from Conductor (advantage?)

Cons:

• reimplement the IaaS API
• extra service