Winged Monkey

Hugh Brock hbrock at redhat.com
Wed Oct 24 20:45:16 UTC 2012


On Wed, Oct 24, 2012 at 04:33:35PM -0400, Scott Seago wrote:
> On 10/24/2012 04:27 PM, Andy Goldstein wrote:
> >On Oct 24, 2012, at 4:19 PM, Scott Seago wrote:
> >
> >>On 10/24/2012 04:14 PM, Andy Goldstein wrote:
> >>>Hi Greg,
> >>>
> >>>How is this different than the "Monitor" (non-Admin) section of Conductor?
> >>>
> >>>Thanks,
> >>>Andy
> >>Hi Andy,
> >>
> >>Greg could expand more, but a simple answer is in this section of the announcement:
> >>>A Winged Monkey is not a ...
> >>>
> >>>... Conductor.  Winged Monkey will avoid providing any type of cloud account
> >>>multiplexing directly.  It will avoid cloud management interfaces.  It will
> >>>not build or push images to back end providers.  And, it will not implement
> >>>quota and cost management.
> >>>
> >>>Instead, it's more likely that Winged Monkey would like to plug into Conductor
> >>>APIs to take advantage of these features.
> >>The "monitor" section of conductor is simply the "application/instance launching and control" section of Conductor. the "admin" section is where providers, users, etc. are managed. It's not really admin vs. admin -- even administrators deal with application-level stuff via Monitor.
> >>
> >>In any case, the above spells out how Winged Monkey differs from Conductor -- and when we say "Conductor" -- if we're talking about launching stuff, that's all handled on the (poorly-named) "Monitor" section.
> >>
> >I guess I'm still confused :-(  I read the "not a Conductor" section you referenced but I don't see any difference, once you strip out the admin section.  You can launch VMs from Conductor, and you can stop them, just like what is proposed for Winged Monkey.  What distinguishes Winged Monkey from Conductor/Monitor?
> >
> >Andy
> The thing is -- stripping out the admin section doesn't change the
> functionality of conductor (although I guess it would make it harder
> to set up providers and users, etc).
> 
> When you go to conductor and launch an instance, Conductor will use
> its provider selection algorithm (based on the configuration of the
> environment, providers, realms, etc) to determine where to launch an
> instance -- and launch it there. There are two key things here (that
> are really the essence of conductor):
> 1) the user launching doesn't necessarily know whether the instance
> will launch in ec2, on RHEV, or wherever -- the system decides that
> based on a variety of internal parameters
> 2) the user launching isn't in posession of the actual
> authentication credentials on the provider (i.e. ec2, etc).
> 
> Winged monkey is a much thinner layer than conductor -- the user
> will explicitly choose a provider endpoint, and (at least from
> what's said above) will already be in possession of the access
> credentials for the provider. You could think of Winged Monkey as an
> "end user application" front end for deltacloud, whereas Conductor
> is more of its own "complex" application, for which Deltacloud is
> just one of several external services it talks to to do its job.

I'll just second Scott's point here and expand on it.

We've had a somewhat difficult time explaining to people what Conductor
*is* over the years, and that is partly because it is in fact too many
things.

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*.

The purpose of Winged Monkey is lifecycle management of VMs or AppForms
in the cloud. Winged Monkey should be happy to use Conductor as a back
end, so that we can expose Conductor's cloud-aggregation mission to end
users. Winged Monkey should also be happy to connect directly to RHEV-M
or OpenStack and launch things there, should our Aeolus user have their
own private credentials they want to use. It will be a far better UI for
lifecycle management for being concerned only with *that one thing*, not
with image building or pushing or cloud aggregation.

Take care,
--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