----- Original Message ----- > From: "Scott Seago" <[email protected]> > To: [email protected] > 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" <[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).
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 > >
