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