----- 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?). > > Scott > > >> Scott > >> > >
