Winged Monkey

Hugh Brock hbrock at redhat.com
Mon Oct 29 19:17:13 UTC 2012


On Mon, Oct 29, 2012 at 01:55:37PM -0400, Matt Wagner wrote:
> On Wed, Oct 24, 2012 at 04:45:16PM -0400, Hugh Brock wrote:
> > 
> > The core mission of Conductor is to allow admins to aggregate cloud
> > providers into a virtual or "synthetic cloud," to dynamically make
> > decisions about what provider will be used to satisfy a given
> > requirement in a given situation, and to track multiple users of a
> > single (or two, or three) cloud accounts. All the other stuff about
> > building and launching and ongoing management is ancillary to that core
> > mission. So if you take away the admin section, really, *there is no
> > Conductor*.
> 
> This is kind of surprising to me. When people ask me what Conductor is,
> I usually say something like, "It's a tool for managing deployments
> across cloud providers." The building and launching, to me, is the
> majority of what we do. The 'About' page on our site describes us as "a
> single, consistent set of tools to build and manage organized groups of
> virtual machines across clouds."
> 
> (Of course, this should all be taken with a grain of salt because it
> uses terms like "Aeolus Composer" and "Aeolus Organizer" which don't map
> up to anything we actually have.)
> 
> Now, Aeolus does allow users to "aggregate" cloud providers, but only
> for use within Conductor itself. There's currently no means to interact
> with them remotely. Dynamically deciding where to launch is a new
> feature, and one that we haven't even made much noise about having.
> 
> Am I the only one surprised to see the project described this way?

I think we are tripping over the delta between what I hope will happen
and what currently does happen... and my expectation that everyone I
talk to has been in all the same discussions I have, which is of course
somewhat (*ahem*) unrealistic.

My statement about the mission of Conductor flows out of the "personas"
document I just emailed to the list a couple of days ago.

I think a pretty good rule of thumb, given the other statements we've
agreed to in this discussion over the last few days, is that at least
from an API + component situation (forget about UI for a minute) we
ought not to have any components in the Aeolus universe that serve more
than one or maybe two of those personas.

Conductor, as it is currently constituted at least, attempts to serve at
least five personas: an infrastructure consumer (wants to launch and
manage things); an application designer (wants to author templates,
author deployables); an application provisioning person (wants to make
sure all the stuff that's required for a deployable is built and in
place); an infrastructure manager (wants to control budget and access to
cloud providers); and a security administrator (wants to make sure
development applications are not running in production and related
concerns).

In serving these personas we had to make a lot of compromises in the
interest of time. The most painful one, according to our users (and our
critics, which I probably hear more of than you guys do), is that we tie
the needs of the "launcher" persona to the needs of the "app designer"
persona and the "infrastructure manager" persona. So the poor launcher
in the Conductor world, who simply wants to pick some things to launch,
must first put on an infrastructure manager hat, and then put on an app
designer hat. Finally they can put on their launcher hat, if they last
that long -- but even then they're constrained in what they can do. They
can't, for example, pick which provider they want to launch on; nor do
we expose for them any provider-specific features, because it would
break the nice abstraction we have designed for the benefit of the
infrastructure manager. Our app designer user has similar problems --
the build management tools in Conductor were always an afterthought,
it's very difficult to tell what is ready to go and what isn't, and
there's no good UI or API (yet) for managing any of it.

The one user I feel we serve *well* with Conductor is the infrastructure
manager. No, we don't (yet) have very good tools for automatic provider
selection, but we do have great support for role-based authorization,
quota management at all levels, good hardware profile managment (need it
for cloud abstraction), a decent API for managing providers, event
logging for tracking billing and usage, etc. etc. This is why I keep
referring to this user's needs as the logical core mission of
Conductor. 

In the end, I believe we're going to wind up with at least 4 apps,
possibly 5, in the Aeolus world: a lifecycle management and monitoring
app for the infrastructure consumer, a design-and-build app for the app
designer, a cloud abstraction and multiplexing app for the
infrastructure administrator, a cross-cloud state machine to serve the
deployment needs of all three users, and possibly yet another separate
monitoring and alerting app. I think it's critical that at least the 4
user-facing apps be able to operate independently of each other. So we
want the lifecycle app to be able to connect straight to a virt provider
in some applications, or to the cloud abstractor in  other cases. We
want the design-and-build app to be able to provide catalogs and app
status to any caller.
 
If you guys want to decide that the current UI for the infrastructure
consumer is awesome and we should go about decoupling that from the
cloud abstraction code, that's a reasonable argument to have. But we
absolutely need the cloud abstraction stuff, and IMO we'd be better
served to focus further attention to the Conductor codebase on providing
better API and UI for that, while splitting off or growing from scratch
new apps that serve the other personas in the group.

Sorry for yet another mailbomb, I hope you enjoy reading it as much as I
enjoyed writing it...

--Hugh


-- 
== Hugh Brock, hbrock at redhat.com                                   ==
== Engineering Manager, Cloud BU                                   ==
== Aeolus Project: Manage virtual infrastructure across clouds.    ==
== http://aeolusproject.org                                        ==

"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey



More information about the aeolus-devel mailing list