RFC: The Broker

Tomas Sedovic tsedovic at redhat.com
Fri Apr 5 13:45:40 UTC 2013


On 04/04/2013 08:27 PM, Matt Wagner wrote:
> On 4/3/13 10:45 AM, Martin Povolny wrote:
>> Hallo all.
>>
>> Together with Tomas, Jan and with contribution of many others we have
>> put together the proposal for the Broker project and put it into a wiki
>> page.
>>
>> https://github.com/aeolusproject/conductor/wiki/BrokerProject
>>
>> This page aims to explain what we want to do, why and how and also
>> suggest some ways how the goal can be reached.
>>
>> We highly welcome your inputs, ideas, comments, opposing suggestions,
>> etc.
>>
>> So, please, read the page and provide your feedback.
>
> Overall, I think this is an excellent summary of the situation. A few
> thoughts:
>
> - We start off by listing three pieces -- app management, cloud broker,
> and a GUI. But in elaborating in the components, we omit the UI. We
> could probably do something with Winged Monkey, or maybe even with the
> ManageIQ stuff going forward. I agree that it should be separate from
> the app management and cloud broker components, but I think the web
> interface is something that needs to exist, somewhere.

With Conductor, we've spent an insane amount of time building the UI 
without ever actually having a usable API. And the first thing we've 
heard from people who actually tried to use the thing was "we need an API".

So I'd rather see us build a solid piece of tech that's can be easily 
automated and introduced into existing environments.

Moreover, using the broker would be no different than using Deltacloud 
(including their client libraries and even the web UI if we do it 
right). I guess that means Winged Monkey, too, if they work with the 
Deltacloud or CIMI API.

And with a good API, the configuration (setting up pools, accounts and 
such) won't be that much of a hassle to a skilled sysadmin -- who 
probably values being able to script it with perl more than a nice GUI.

Once we have this foundation, we can build the UI (web and cli) on top 
of it. It'll probably end up being more robust and help us validate the 
API, too.

>
> - As I read the bit about cloud broker, having not been involved in the
> conversation for a little bit, it occurs to me that it sounds a lot
> closer to what Deltacloud does than Conductor did. It almost sounds more
> like an extension to Deltacloud than a stand-alone app, at least at a
> high level.

Remember that under ideal circumstances, Deltacloud as a code base need 
not exist because everyone implemented the Deltacloud (or CIMI or any 
open standard) API.

Also, you can have Deltacloud without the broker and you can have the 
broker without Deltacloud. To me, that seems a reason enough not to 
merge them (though there's still opportunity to share code).

Then again, what is now known as Aeolus Conductor used to be called 
Deltacloud Aggregator (and Deltacloud Portal before that) and it was 
much closer to the broker concept than what we have now. Even then, 
though, they lived in separate repositories and were mostly written by 
different people.

But if the Deltacloud community (and Apache) are okay with having the 
broker under the Deltacloud banner, I'm fine with it. Might help us with 
community involvement and visibility.

>
> Overall, I think this page is a really good summary of previous
> discussions, and is quite helpful to me. I find I'm gravitating towards
> option 2, though not necessarily out of any strong architectural merits.
>
> -- Matt



More information about the aeolus-devel mailing list