-
Notifications
You must be signed in to change notification settings - Fork 27
BrokerProject
We think that Conductor is a very complex beast that lacks focus. It's hard to describe it to potential users because it does so much and often not very well. Moreover, the complexity makes it hard to contribute back as well.
Looking at the outside world and comparing it to Conductor, there seem to be two or three separate pieces with their own use cases that we've tried hard to jumble together:
- Cloud app management
- Cloud broker
- All-encompassing graphical user interface
Examples of app management tools would be AWS CloudFormation and OpenStack Heat. They are in the same space as our Deployment/AppForm management, but have more features and focus. They don't manage individual instances, pools, provider accounts, images, hardware profiles, credentials, quotas, etc.
By a cloud broker we mean a piece of software that puts together various cloud providers (and in-house resources) to form a virtual-cloud provider. Such provider will hide the details about what resources are being used to satisfy particular request from it's users and will use some logic to make the best choices based on some criteria such as price, location, resources available, error rate etc.
The broker doesn't deal with app management. A user talking to a cloud broker would see it as just another provider (i.e. on the same level as EC2, OpenStack or oVirt). Of course, apart from the provider API it needs a configuration/management API where one would set up the pools, accounts, users, and quotas.
Let's split the two. Even better, let's delegate all the app management work to Heat since that's an open source project that's already dedicated to doing just that. We could then focus on building a cloud broker that can either be used stand alone or in conjuction with Heat.
- 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.
- deltacloud is a lib
- there is a stateful service (app) on top of it which implements CIMI standard
- there is an additional and optional broker service
- CIMI app and Broker can be both mounted as rack apps
- 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.
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
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.
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.
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