Winged Monkey

Jaromír Coufal jcoufal at redhat.com
Fri Oct 26 14:00:30 UTC 2012


On 25.10.2012 22:32, Hugh Brock wrote:
> On Thu, Oct 25, 2012 at 07:30:55PM +0200, Jaromír Coufal wrote:
[snip]
> [many worthy ideas snipped]
>> In Winked Monkey, as I found out, there is not even counted with
>> these necessary steps (talking about steps 1 and 2). Adding these
>> features, we are slowly going to lighter version of Conductor.
>> =
>> What I really like about Winked Monkey is, that we started to think
>> about UI from different point of view and started to care just about
>> users who are running images. Which definitely can inspire and help
>> us to improve UX.
>>
>> Another value I see in Winked Monkey project is, that we will
>> approach broader audience and community of users - those having just
>> few images across different providers.
>> But my question is, if this segment of users is big enough? Because
>> from my point of view, being individual (or small company) running
>> just few instances, I am usually choosing one provider and running
>> all instances there - in this case I would not search for
>> application unifying UI for running instances.
>> (maybe I am wrong on this one)
>> =
>> Having talks about this particular type of users and creating
>> muck-ups for their use-cases is definitely valuable for us. I feel,
>> and I am sorry to express my worries, that having stand-alone
>> application as Winked Monkey is (especially implementation and
>> maintenance) would consume lot of effort and resources. I think,
>> that we can achieve similar result with improving Conductor for less
>> effort.
> Thanks so much for spending so much time thinking about this
> Jarda. I think your analysis of the details is accurate, but I'm going
> to dispute the conclusion you come to by taking a big step backward to
> look at the whole picture of Aeolus.
>
> (This is going to be a major topic of conversation in our meetings in
> Brno week after next I hope.)
>
> How will we know Aeolus is successful as a project? What are its goals?
>
> I believe the goal of Aeolus has always been to make *all* cross-cloud
> operations as easy as using a single cloud, to the extent that it is
> possible to do so. I believe this is a worthy goal, because proprietary
> cloud APIs and tools are as dangerous as the proprietary compilers of
> the 1980s that inspired the free software movement. I believe we have
> made good progress toward this goal although we have a long way to go
> yet.
I agree. What I like on this point is that you mentioned *as easy as 
using one cloud*. It evokes in me, that it should be *easy to use* and 
what I am a little bit feeling from previous conversations in this 
thread is that lot of us take Conductor as administrative tool, which is 
supposed to be difficult to use and difficult for non-technical user to 
understand it. And I think this is one part, where I disagree, because I 
think it doesn't have to be this way and we can make it user-friendly 
for normal users as well.

> I believe we will know Aeolus is successful when we Red Hat folks
> comprise less than 50% of the developer community, and when we (Red Hat
> Inc.)  have to have significant arguments with that community in order
> to get features in that we want in our productized version of it. By
> this measure Aeolus has made 0 progress toward being successful in its
> lifetime :(.
I have to agree. What I think that can be one of the biggest problems is 
worse usability for users (technical, non-technical, doesn't metter). We 
have great functionality, but users are not aware of it, because it's 
hard for them to get oriented in our system - it's too complex and by 
growing, it lost some nice structure. I hope that getting it more 
user-friendly and more clear what it does (breaking into parts?), will 
improve our ratings :)

> Finally, I believe that unless Aeolus is successful upstream, it will
> eventually fail as a product or be absorbed into something else. I
> believe the clock for this is ticking. We have no time to lose, in other
> words.
I think, there is potential for Aeolus to be successful as a product.

> So, how can we build a user and developer community from the ground up,
> around a problem space as esoteric as "save the world from cloud
> lock-in"?
>
> This is hard work but there are certain lessons we can learn from other
> community projects that are successful. I'll take OpenStack as a model
> here; although it, too, is far from perfect, it is by any measure a
> successful upstream project.
>
> Lesson 1: A single upstream project should do one thing,
> well. Deltacloud is actually a good example of this; it has profited by
> limiting itself to a stateless cloud API. Most of the OpenStack
> services -- Glance, Swift, Cinder, Nova, Quantum -- also conform to this
> principle. Heat has also explicitly tried to limit itself to one key
> feature -- manage multi-tier applications on OpenStack -- with
> reasonable success.
> Lesson 2: Build things in small pieces that a single developer can
> understand without too much effort. Our community will, in the end, be
> built by interested developers who find a piece of what we're doing
> valuable to something they're doing. We may at times finding ourselves
> doing *more work* to keep things small. This is a perfectly reasonable
> cost for the benefit we will derive from upstream adoption.
> Lesson 2b: Keep project teams small. If a project is complex enough that
> it needs more than three developers to make forward progress in it, it
> will soon be incomprehensible to outsiders, thereby failing Lesson 2.
It is reasonable and very good point. There might be a small danger in 
this approach is, that we might get locked in development of umbrella 
project (Aeolus) by waiting on dependencies of small sub-projects (one 
team waiting for the other one). So I just want to say, that we should 
be aware of this fact and take it into account for our cooperation if 
this is the case.

> Lesson 3: The umbrella project for a set of individual projects should
> have good, open governance, in which not just coding standards and API
> styles but also the overall project goals and metrics are agreed by a
> committee in an open process that has at least some degree of
> formality. In other words, it should be possible to debate the structure
> of an API, put it to a vote, and have it be a settled question from
> thereon. Otherwise the individual projects under the umbrella will fail
> Lessons 1 and 2.
> Lesson 4: The umbrella project must itself have a compelling goal that
> gets people excited and is easily understood. OpenStack is a
> free-software reimplementation of EC2. Everybody wants private cloud and
> everybody wants to not be locked in, so OpenStack is really
> compelling. (Note Aeolus has quite similar goals, just on a meta-cloud
> level.)
> Lesson 5: The umbrella project has to get talked about at a lot of
> conferences by a lot of different people.
In conclusion all 5 lessons are very reasonable and I like it.

> Now, let's measure the current state of Aeolus against these rules,
> where Aeolus (for the sake of argument) is comprised of Deltacloud,
> Image Factory/Oz, Audrey, Conductor, and recent arrivals Alberich and
> Tim.
>
> Deltacloud largely succeeds across all of the lessons above, which may
> explain why it is one of two Aeolus projects (with Oz being the other
> one) that has gotten significant traction upstream.
>
> Image Factory does well on goals 1 and 2, although it has suffered by
> being tied to an Image Warehouse tool that no one really understands the
> purpose of.
>
> Oz has in fact gotten a lot of interest upstream although as far as I
> know it hasn't drawn too many actual contributions. But it certainly
> does well on goals 1 and 2 -- it does one thing well, and it's certainly
> small enough that a single developer can easily grasp it.
>
> Tim is a bit too early to rate, but it appears to pass lessons 1 and 2,
> as does Alberich.
>
> Audrey is also small, but it suffers from being directly tied to
> Conductor, so in a sense it fails lesson 1 by doing nothing at all on
> its own.
>
> Now... let's take a look at Conductor. Conductor:
>
> * Provides a UI for building and pushing images and wrapping them in
>    deployables
> * Provides a UI for launching deployables and setting launchtime
>    parameters for them
> * Provides a UI for managing deployables and instances while they are
>    running and tracking them over time
> * Provides the back end facilities for doing the launching itself,
>    handling failures and exceptions, and actually setting the config
>    values post launch
> * Provides an extensive and complex "matching" mechanism that, given a
>    user's privileges, the requirements of the application being launched,
>    the relative weight of the particular cloud providers that are
>    available to launch on, and the user's quota on each provider, will
>    choose a suitable cloud provider to launch on
> * Provides all the UI required to manage the inputs to the matching
>    mechanism
> * Provides full RBAC services for all of the entities in the system
> * Provides a UI for managing the RBAC system
> * Provides an event logging facility so that users can retrieve and
>    track instance lifecycle events
> * Provides graphs of the event logs
>
> Clearly Conductor fails lesson 1. With more than 50 model classes and at
> least one pair of controllers that actually do the same thing, it also
> fails lesson 2.
Yes, Conductor is very complex. Breaking into parts is good idea. These 
parts need to be consistent and cooperative. What I see Conductor can 
do, is to split into modules. Question is about which granularity to choose.

Haven't thought about it, but we can have modules of UI for managing:
* images
* deployables
* deployments
* permissions
* users
* providers
* notifications
* ...?

It's very brief list of logical parts from my UI point of view, there 
might be lot of other ones.

Then Conductor itself should join modules and ensure their cooperation.

> Finally, let's look at the umbrella project, Aeolus. Aeolus clearly
> fails lesson 3 because historically *I* have provided the governance
> with my mighty ><}}}*>. While I find this method of governance quite
> satisfying, I am forced to admit that it neither scales nor works for an
> upstream project where there might be people who do not work for
> me. Sigh. (Scales, get it? The ><}}}*> doesn't *scale*. I kill me!)
>
> Does Aeolus pass Lesson 4? If not, we should all hang it up and go do
> something else. Fortunately, I think Aeolus does pass lesson 4,
> handily. I think there is real need for a set of cross-cloud tools, from
> small shops that have nothing but an EC2 account and a few in-house
> machines running VMWare, to individual developers who want to launch a
> multi-tier app on whatever the cheapest public cloud happens to be at
> the time, to larger organizations that want to provide a fully managed
> self-service environment to internal users. I think Aeolus is well
> positioned to fill this need, and I've seen other closed source tools
> that do so I'm confident the need is real.
So am I.

> What about lesson 5? We have tried to make some headway here but we've
> not done well at coming up with a good community marketing plan and
> sticking with it. My hope is that improving our score on lesson 3 will
> help with this.
>
> So, where does this leave us?
>
> 1. We need to fix the governance. This means that you folks, the Aeolus
> developers, need to figure out what model we are going to follow for
> making architectural decisions, API decisions, coding style decisions,
> and so on, put it in place, and stick to it. I would suggest that that
> model be more sophisticated than "argue about it on the mailing list and
> never come to a conclusion," which is what we've done to date.
I have to admit, that sometimes I feel, that there are lot of 
discussions on mailing lists (or GitHub issues, or IRC) and there is no 
output from that. One approach to improve can be:
1) introduce intentions on some call (very briefly - just introduction) 
- people are aware
2) send some RFC, give some time for discussions, spreading ideas and 
let people think about that a little bit more - brainstorming of ideas, 
preparation
3) people who are interested in involving should meet at rounded table 
(call) and have moderated discussion, so the discussion leads to some 
result, which in the best case we should get in the end of meeting - 
having conclusion, starting implementation

It doesn't have to be perfect - nothing is. We can start in some way 
(which seems to be the best for us) and we can adapt regarding 
situations. But we need to start to be active and not just wait on some 
"natural" conclusion on mailing list.

> 2. Once we've fixed the governance, I believe we need to fix Conductor,
> and I believe that fixing Conductor requires breaking it into individual
> pieces that do one thing, well. One set of suggestions for those pieces,
> which you may or may not agree with, is the following:
>
> * A standalone self-service portal (i.e. Winged Monkey). Provides
>    management of single instances or n-tier apps. Will work all by itself
>    in front of rhev-m, openstack, vsphere, ec2, rackspace, or will work
>    connecting to Heat connected to one of those things, or will work
>    connected to Conductor. Appeals just as much to the individual
>    developer or guy-with-a-webapp as to the corporation with
>    self-service users connecting to Conductor pools.
>
> * A standalone catalog manager service. Provides API to retrieve deployables,
>    resolve the templates they require into actual build images (via
>    querying Tim presumably), answer the question "what can I launch on
>    this cloud."
>
> * A standalone app design/catalog manager UI that would provide the app
>    designer a GUI for Tim and the catalog manager
>
> * A launching/state tracking mechanism -- i.e. Heat. Takes a
>    CloudFormations template and launches it on a given cloud. Tracks the
>    state of the instances in the template and manages failures
>    appropriately (by restarting, auto-scaling, etc.)
>
> * An event tracking service. Provides up-to-date views into instance and
>    app events collected over time via an API. Clients would include
>    Winged Monkey and other sophisticated reporting services.
>
> * A cloud abstraction layer or "synthetic cloud" provider (the real meat
>    of Conductor). Given configuration input by an admin, aggregates a set
>    of cloud accounts and providers into a single cloud that it presents
>    to the user via an API. Allows admins to shape provided clouds
>    according to cost and resource needs, provider track record
>    ("quality"), quota, other factors.
>
> * Other thin UI layers as appropriate. I would prefer to see us move to
>    the pattern OpenStack and OpenShift and Katello (to some extent) are
>    using here, which is a set of services that provide APIs only
>    (probably REST but I don't really care to be honest) and a stateless
>    UI layer in front -- model code, sure, but no access to storage other
>    than via the constituent projects that make up the back end. (This is
>    another reason we need better governance.)
Ah, I see, you already have a list into which parts to break Conductor 
:) Few lines above, I wrote some list of Conductor components as well, 
but mine is more logical grouping than functional components.

> (Note I've left out Alberich here, not because I don't think it's
> important but because it's more of a building block that all of these
> services might use to implement their own authorization schema. There
> will be other things in Conductor that fall into the same category.)
>
> This is, more or less, the list of things that Conductor does. No wonder
> it has 50+ model classes...
>
> Now, the above is just my list. I think it's a pretty good list, and
> I've thought about it a lot, but it is not a mandate (see Lesson 3). You
> can see though that the reasons for doing something like Winged Monkey
> go way beyond the merits of Winged Monkey itself, or any kind of
> WM-vs-Conductor contest. WM is much more tied to the idea of let's make
> Aeolus a great upstream project by taking the bits that might be useful
> on their own and making them available for use. I think it's tough to
> argue with this approach, frankly.
I have absolutely nothing against splitting Conductor into parts. I am 
on the same page with you on this.

About Winked Monkey, I think that it is great to have separate module 
for this functionality, it definitely is. What I am worried about is, 
that we take part of Conductor, start to duplicate it as an stand-alone 
project - new UI, new models, etc. But development of the same 
components in Conductor will continue. When time comes, we take Winked 
Monkey, use it in Conductor by throwing away the components which we 
were trying to improve during Winked Monkey development process? Maybe I 
understand it wrong way. But that's the core of my worries - duplicating 
work and one of the results will be thrown away.

> Well... that's a lot of writing for a Thursday afternoon. If you've made
> it this far, please, let me know if you think I'm nuts or if you have a
> better list of discrete Conductor components. Also, proposals for
> governance models are encouraged...
>
> Take care,
> --Hugh
>

Thank you for this very detailed explanation of your thoughts, Hugh. I 
have nothing to disagree directly, all my responses are above. Regarding 
lessons - I didn't know them before, from my point of view, they 
describe situation nicely. Happy to learn something new :)

Take care
-- Jarda



More information about the aeolus-devel mailing list