Hi Jaromir,
----- Original Message -----
From: "Jaromír Coufal" <jcoufal(a)redhat.com>
To: aeolus-devel(a)lists.fedorahosted.org
Sent: Thursday, October 25, 2012 1:30:55 PM
Subject: Re: Winged Monkey
Hello folks,
I was also feeling and saying (as Matt wrote few mails ago), that
with
Winked Monkey, we are going to duplicate part of Conductor and trying
to
avoid its difficult parts.
=
My idea about how we can deal with this situation in Conductor is
based
on user privileges and hiding sections, which user cannot access. Let
me
explain on simple example:
* Situation (based on Winked Monkey purpose):
- We have a user who doesn't (or shouldn't) care about creating
images,
pushing to providers, setting environments or pools, (...).
- User wants just to start and stop images, which he has on different
provider accounts.
* One suggestion how we can deal with this situation:
- When I restrict user, that he can't create images, manage
providers,
realms, hardware profiles, (...) so he can just and only launch
images,
he won't be able to do anything else in the system. In the best final
way, he won't be able to see any other sections he has no access to,
so
he will be able just to see section where: 1) are running instances
and
2) the other one with images he can launch. Nothing else. No
providers,
no realms, no hardware distractions.
- Furthermore, having set some default realms, default hardware
profiles, (...) and if user would not be allowed to change them, he
will
have nothing to set up in launching process.
- In the end he will just see running instances and images he can
run.
After hitting launch button, his instance will "automegicaly" run,
because he can't set up anything.
And that's actually everything what Winked Monkey should provide,
right?
I think we can get similar effect in Conductor.
=
Further more, it's not that simple how it seems (if I get it in a
right
way).
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.
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.
By creating type of user in Conductor, who can only:
1) add provider account,
2) import images from provider,
3) start/Pause/Stop
... we will have this requirement satisfied. And he will see nothing
else (regarding permissions).
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.
The base assumption being that creating provider accounts and messing
around with images are necessary steps for a non-technical user.
These might be necessary steps within the context on Conductor. But,
so far, I'm not convinced they have to be necessary steps when outside
the context of Conductor. And, definitely shouldn't be necessary
steps for the non-technical user.
=
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.
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).
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
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.
=
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.
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.
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.
-- Jarda
--
Jaromír Coufal
Interaction Designer
Red Hat Czech s.r.o.
Mobile: +420 724 595 508
E-mail: jcoufal(a)redhat.com
IRC: jcoufal at #cloudforms-ui, #aeolus, #brno