Winged Monkey

Hugh Brock hbrock at redhat.com
Wed Oct 24 20:50:01 UTC 2012


On Wed, Oct 24, 2012 at 04:43:54PM -0400, Scott Seago wrote:
> 
> On 10/24/2012 04:40 PM, Greg Blomquist wrote:
> >
> >----- Original Message -----
> >>From: "Scott Seago" <sseago at redhat.com>
> >>To: aeolus-devel at lists.fedorahosted.org
> >>Sent: Wednesday, October 24, 2012 4:33:35 PM
> >>Subject: Re: Winged Monkey
> >>
> >>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 agree with that.  With the one caveat being that it remains an
> >eventual goal of Winged Monkey to use Conductor as a "back end
> >provider".
> >
> >Conductor has a lot to offer from:
> >   * account multiplexing
> >   * quota management
> >   * state monitoring
> >Conductor might even one day supply logic or API for cloud chargeback
> >(maybe?).
> >
> For this, would you want to be able to access conductor via the
> deltacloud API (i.e. we write a deltacloud driver for conductor), or
> would conductor be a "special" provider and you use the conductor
> native API? The former would let you use most of your code as-is,
> but you'd lose out on conductor-specific stuff (and someone would
> need to write that driver). The latter would let you do everything
> conductor can do (but you'd need to write a lot more code for winged
> monkey).

My thought was that the "right" API to use would be something more like
the Heat API, since Conductor already understands multiple instance
deployables. We want Winged Monkey to be able to connect to Heat anyway,
so if Conductor exposes an equivalent API, that would reduce the effort
for WM. I'm willing to be persuaded otherwise however. It may be that we
decide Conductor doesn't in fact care about multi instance deployables
and we just want it to expose a DC API, or we may want to do yet a third
thing. This is going to be a big topic at the Brno meetings in a couple
weeks. 

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