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