Winged Monkey

Greg Blomquist gblomqui at redhat.com
Wed Oct 24 20:52:10 UTC 2012



----- Original Message -----
> From: "Scott Seago" <sseago at redhat.com>
> To: aeolus-devel at lists.fedorahosted.org
> Sent: Wednesday, October 24, 2012 4:43:54 PM
> Subject: Re: Winged Monkey
> 
> 
> 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).

That's a really good question.  I _think_ the idea would be to access
the conductor API directly.  But, we're honestly still so far away
from that point.

Right now, we're dropping cloud credentials in a configuration file
and having the app proxy connections to the back ends on behalf of
the current user.

It's all very thrown together at this point.


> 
> Scott
> 
> 



More information about the aeolus-devel mailing list