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, [email protected] == == 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
