On 10/24/2012 01: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
Hey Greg,
Thanks for sending this out. Sound promising.
Some comments:
1)
Reading through your user stories it's not clear to me how
resources WM will use are to be generated. How are application
blueprints and images to be created?
I understand that pre-canned images are available on EC2 but
what about support for less popular back ends? Isn't something
needed to help users populate images and create application
blueprints?
A repository of application blueprints and images perhaps?
2)
Is DeltaCloud going to be used to access all supported back ends?
I think it would be valuable to use a common API provider like DC
and add DC drivers where needed or perhaps CIMI, which DC
supports.
3)
I think Matt Wagner makes some good points. It seems to me that
that WM is sort of like Conductor-Lite. Perhaps it might be valuable
to explore providing a pared-down Conductor that provides the user
experience you envision for WM.
If I'm off in left field on any of these let me know.
Thanks!
Joe
