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.
Regards!
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.
- 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.
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
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
On Fri, 2013-04-05 at 15:45 +0200, Tomas Sedovic wrote:
- 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).
I keep going back and forth in my head what the right combination is there - clearly, for the public/pool API there might be some value in implementing that as a DC driver (it would save the broker from worrying about the minutiae of dealing with the web side of API's)
Just as clearly, on the administration side, the broker is a DB-backed web service, and needs to do what's best for such an app; the mechanics of implementing a RESTful API are a much smaller concern on that side compared to the overall work involved.
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.
I think that's something to consider very seriously: the broker could definitely be its own Deltacloud subproject, with separate code base etc. We'd need to weigh the pros and cons carefully.
David
aeolus-devel@lists.fedorahosted.org
-
David Lutterkort -
Martin Povolny -
Matt Wagner -
Tomas Sedovic