Winged Monkey

Andy Goldstein andy.goldstein at redhat.com
Wed Oct 24 20:27:13 UTC 2012


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

> Scott
> 
>> On Oct 24, 2012, at 1:21 PM, Greg Blomquist wrote:
>> 
>>> What is Winged Monkey?
>>> 
>>> The idea for Winged Monkey started as a simple end user cloud access portal.
>>> We are trying our best to stick to this idea.  But, it requires a certain set
>>> of consistent key ideas:
>>> 
>>> * Winged Monkey is geared towards users and not administrators
>>> * Winged Monkey should provide simple usable access to cloud back ends
>>> * Winged Monkey cannot do anything that a back end provider cannot do
>>> 
>>> In the end, we want it to be an attractive, simple, and intuitive user
>>> interface that makes the resources of multiple underlying cloud providers
>>> accessible to non-technical users who are focused on achieving their goals
>>> rather than on attempting to understand the "cloud".
>>> 
>>> 
>>> Why Winged Monkey?
>>> 
>>> Originally, the name started as joke.  But, like all project names, we
>>> rationalized the name to fit the project.  The monkey only knows how to do
>>> simple things.  If you teach the monkey, it can eventually learn to do more
>>> complex things.  It's still just a monkey, though, and will never be the
>>> smartest primate in the room.  It's one advantage is that it has wings, so it
>>> can play in the clouds.
>>> 
>>> 
>>> Monkey Goals
>>> 
>>> The primary focus is to make a simple user interface for cloud resource
>>> consumption.  The simplest interface we think we can provide is one where a
>>> user can start/stop VMs and launch pre-existing applications.
>>> 
>>> The simplest ideas are sometimes the hardest to implement.  For instance, how
>>> do we provide the ability to start/stop VMs against various back ends while
>>> trying to shield the user from having to configure the access to those back
>>> ends?  Clearly there needs to be an administrative component.  We're just
>>> doing our best not to worry too much about the administrative side at this
>>> point.  The fact is that there are several other applications that handle
>>> cross cloud administration.  Eventually, we'll likely just tie into one of
>>> those systems to off load the administrative
>>> portions.
>>> 
>>> If it turns out we need to implement something that's already implemented by
>>> another application, we'll grudgingly do it.  But, we're gonna exhaust every
>>> potential integration point, first.
>>> 
>>> 
>>> 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.
>>> 
>>> ... Deltacloud.  Winged Monkey is an end-user application, and not intended to
>>> be an API.
>>> 
>>> If Winged Monkey takes advantage of Conductor's API for account multiplexing
>>> and cloud cost/quota, it will in turn be using the Deltacloud API to connect
>>> to cloud back ends.
>>> 
>>> ... Heat API.  Winged Monkey will not have a concept of stack templates or
>>> managing the high availability of applications running in the cloud.
>>> 
>>> Winged Monkey will rely on APIs like Heat to provide stack (or application)
>>> deployments and health monitoring.
>>> 
>>> ... Foreman.  Winged Monkey will not present puppet classes or manifests for
>>> configuration management.  It will not contain administration for networking
>>> configuration of hosts or guests.
>>> 
>>> Winged Monkey could use the Foreman API to launch systems that connect to a
>>> puppetmaster for configuration management.
>>> 
>>> 
>>> Progress so far
>>> 
>>> Everything we've done so far has been in the vein of brainstorming.
>>> 
>>> Jeremy Perry has put together some excellent wireframes[1] that nicely convey
>>> the theme of simple user interface for consuming cloud resources.
>>> 
>>> We threw together some high level user stories[2] that try to capture what we
>>> would want this thing to do.
>>> 
>>> And, I've started an extremely simple rails app[3] that attempts to meet
>>> Jeremy's wireframes.  The current goal of the rails app is to connect directly
>>> to oVirt and show what pieces of the proposed user interface can actually be
>>> provided.
>>> 
>>> 
>>> Milestones
>>> 
>>> We're still working on these.
>>> 
>>> 
>>> Call for help
>>> 
>>> We are in need of people who want to explore this idea further.  We're looking
>>> for people who:
>>> 
>>> * are good at visual design and user experience
>>> * have interesting ideas about servicing end users of cloud resources
>>> * dream in ruby/rails
>>> 
>>> Initially, we want the team to stay small.  There's not a lot of work to divvy
>>> out right now, so there's not a immediate need for a bunch of helping hands.
>>> 
>>> But, we also want feedback.  If you think we're heading down the wrong path,
>>> speak up!  If you have ideas about how to make this idea work, speak up!  If
>>> you just wanna find out why we would do this, speak up!
>>> 
>>> 
>>> [1]: https://github.com/wingedmonkey/documents
>>> [2]: https://github.com/wingedmonkey/documents/wiki/Winged-Monkey-User-Stories
>>> [3]: https://github.com/wingedmonkey/wingedmonkey
>>> 
>>> ---
>>> Greg
> 




More information about the aeolus-devel mailing list