Winged Monkey

Scott Seago sseago at redhat.com
Wed Oct 24 20:33:35 UTC 2012


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.

Scott

>> Scott
>>




More information about the aeolus-devel mailing list