Hi Jaromir, ----- Original Message ----- > From: "Jaromír Coufal" <[email protected]> > To: [email protected] > 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: [email protected] > IRC: jcoufal at #cloudforms-ui, #aeolus, #brno > > >
