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
>