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