Winged Monkey

Jaromír Coufal jcoufal at redhat.com
Fri Oct 26 11:59:56 UTC 2012


Hi Greg,

thank you for your answer, there are few reactions within the text.

On 25.10.2012 21:53, Greg Blomquist wrote:
> Hi Jaromir,
>
> ----- Original Message -----
>> From: "Jaromír Coufal" <jcoufal at redhat.com>
>> To: aeolus-devel at lists.fedorahosted.org
>> Sent: Thursday, October 25, 2012 1:30:55 PM
>> Subject: Re: Winged Monkey
>>
>> Hello folks,
[snip]
>> There are three steps, which each user always needs to follow if he
>> wants to manage provider images:
>> 1) Connect to provider account - add account details to our
>> application
>> (our system needs to connect to the provider so we can manage his
>> instances)
>> 2) Import images from selected provider account (otherwise we have
>> nothing to manage)
>> 3) Start/Pause/Stop images.
>>
>> So both Winked Monkey and Conductor always need to cover these steps,
>> right?
> I would argue that perhaps this is only true within the context of
> problems that Conductor solves.
I am more thinking out loud than saying that this is the only true.

> However, I do not agree that when we're not thinking about how
> Conductor works we have to assume a user must necessarily complete
> steps #1 and #2 to accomplish #3.
>
> You're absolutely right that these types of things must have happened
> at some time.  But, I'm simply suggesting that there should exist a way
> for a non-technical user to accomplish step #3 without ever laying a
> hand on step2 #1 and #2.
Yes, I get the suggestion and it would be great if we can forget about 
steps #1 and #2. Maybe I am just missing something, but when I am trying 
to imagine user getting Winked Monkey for the first time, he runs it and 
there is no content in it. How will the content get into Winked Monkey 
if you say that user wouldn't have to lay hand on this part?

Regarding this, my thoughts lead to one thing:

So called non-technical user have to get somehow the content, otherwise 
he has nothing to run. So he:
1) has to get (import) content by himself (steps #1 and #2) or
2) somebody has to get it for him (current Conductor approach)

And if we get to point that somebody will do this for him, we are 
getting slowly to Conductor permissions. Somebody creating (importing) 
content and then user just running instances.

[snip]

>> =
>> 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.
> Great!  I look forward to any feedback or input you have here.
I am happy to bring as much feedback as possible.

>
>> 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)
> Honestly, we're never gonna produce and application that sits
> between the single user managing only a few VMs and their cloud
> provider. There's nothing that's going to compel that user to use
> yet another interface other than the one provided by the cloud
> company.
>
> If they're managing VMs running on their own hardware, it's going to
> be hard to convince them to run anything other than just
> virt-manager (or, the new boxes interface).
Agree on this one.

> The only scenarios that I think make any sense when thinking about
> throwing a separate user interface between a user and their cloud
> resources is the user that has either:
>
>    a) tons of VMs to manage, or
>    b) various cloud back connections to wade through
Yes, agree on this list, this is the same segment for Conductor as well 
as for Winked Monkey.

> In either case, giving the user some kind of application that might
> simplify what they want to do right now could be a good thing.
>
> The key is to determine the right user to focus on.
>
> Conductor focuses on the administrator.  Granted, there's potential
> to dynamically reduce the scope of Conductor for each different
> type of user that logs into an instance of Conductor.  But, as you
> pointed out earlier, there are pieces to the experience in
> Conductor that are intrinsically administrative (setting up cloud
> accounts and managing image lifecycles). These are the things that
> I don't think should ever burden a non-technical user.
>
> Winged Monkey, on the other hand, focuses on the non-technical user.
I understand, Greg. What you are trying to do is to split administrative 
part from the common user's one. But if this is the case, the 
user-portal still should somehow connect to the administrative part (and 
it might be Conductor, or EC2 directly, or I don't know who) and get 
content from there.

What you are saying is, that Conductor is for more technical experienced 
users and Winked Monkey is for non-technical ones. Conductor is much 
more complex, but as I said - by applying permissions and default 
options, user will not be burden by unnecessary details.

>
>> =
>> 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.
> Two things need to be said here.
>
> 1)  You're right.  Conductor should continue to improve.  Angus has
> said as much in another section of this same thread.  By all means,
> Conductor should become the very best it can be.
I havn't been thinking or saying that Conductor development will stop. 
What I just wanted to take into account is that we can (and from my 
point of view, I would love to) reach similar result with Conductor.

> 2)  We're an R&D group.  It is specifically our decree to investigate
> solutions.  Granted, we have an application that's in the wild and
> is supported.  This means that we have to keep resources dedicated
> to making sure this application meets its support agreement with
> customers.  I have this same commitment with the audrey slice of
> aeolus.
>
> But, we shouldn't let that fact stop us from investigating other
> options.
Well I definitely agree, that it shouldn't stop us from trying 
investigating options and finding new ways how to succeed. I understand 
why you are trying to come out with this project and I didn't say that 
we shouldn't do it.

I just wanted to raise some of my thoughts and the feeling that we might 
be partly duplicating Conductor's effort.

> Don't take this as a directive to drop everything related to
> Conductor and start devoting time to Winged Monkey.  You should only
> get involved if it actually makes sense for you to do so.
Oh, no worries, I don't take it directive. I just wanted to bring out my 
thoughts, which might help to see it from different point of view. I 
don't say I am right, I don't say that these are my thoughts I will 
insist on. Please, take it more like discussion about Winked Monkey and 
Conductor, which helps to make the project more clear (at least to me).

-- Jarda



More information about the aeolus-devel mailing list