----- Original Message -----
From: "Scott Seago" <sseago(a)redhat.com>
To: aeolus-devel(a)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?).
Scott
>> Scott
>>