On 10/24/2012 04:40 PM, Greg Blomquist wrote:
----- Original Message -----
From: "Scott Seago" <[email protected]>
To: [email protected]
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).
Scott
