Conductor structure, concept, main processes - notes in advance for Developer Conference Brno 2012
by Jaromir Coufal
As all of you are certainly aware, the developer conference in Brno is
right behind the door. There are going to be talks about various topics
and I think it would be great opportunity to discuss structure and
workflows in Conductor as well, because right now, we are not very good
at it.
One of my presentations will focus on this topic and I hope that we will
collect lot of feedback from you and discuss it. Hopefully in the end of
conference, we will have Aeolus all done and programmed :)
I don't wanna surprise you with something completely new and start
discussion about something what just jumped in front of your eyes.
That's why I am sending this e-mail in advance, trying to introduce you
few of my ideas. I don't wanna get into many details here, that's what I
plan to do at the conference, but I hope that giving you brief basics in
advance would be useful. If you are interested, you have chance to look
at it and think about it a little bit more before we discuss.
I tried to improve a structure and navigation of our application and
together with proposing new concept and workflows, I believe, that in
the end, we will manage to make user's life easier.
=============
Conductor structure
[1] http://conductor.jaromircoufal.cz/conductor_navigation.png
It's not very different from the current one, but together with
following improved areas of concept and processes, also small changes
play big role in the end. I also tried to reflect main personas, so if
they have some restrictions, they will see just sections relevant to
their role.
I will just list main categories, underlying layer is captured in mind
map (see link [1]).
** Dasboard* - welcome page informing about everything what happened in
the system (available just through logolink)
There are three major categories:
** Cloud Environments* - everything what is related to active elements
(running instances)
** Catalog* - our not active content (templates / outlines, images)
* *Cloud Providers* - places where we actually run the content
And one important for managing access to particular parts of our app:
** Users* - list of users, groups and their permissions
============
Conductor concept
[2] http://conductor.jaromircoufal.cz/conductor_concept.pdf
Just an example of the concept. Content in it is just for example purposes.
* For managing all elements, I think that 2-pane layout would do a
miracle here (list on the left, details on right)... [2] - page 11
* Right after entering the section (no selected item), there should be
statistics information related to the section... [2] - page 9
* There are three different views, regarding user's needs... [2] - pages
11+12+13
=================
Main Conductor Processes
[3] http://conductor.jaromircoufal.cz/conductor_processes.png
I walked through three main user needs based on several talks. There is
not captured how it is related with Conductor right now (e.g.
Environment or Pool dependencies), it's just based on user expectations
and my view, how I designed them to be effective.
*
* Create image* - we just want to specify what will the image contains
inside.
* *Prepare for launch* - now comes the step when we want to launch the
image, so we need to specify few parameters. After setting them, we can
launch it right away or save it as template (deployable)
* *Launch* - we get overview page with all pre-set parameters. We don't
wanna care about setting anything, just launch... [3] - Quick launch. Or
we want to edit some parameters, let's hit to edit them. After editing,
I can save it as new template (deployable), overwrite current one or
just launch... [3] - Advanced launch. There are not two separate
buttons, these two describe one view, but two different approaches (also
might be restricted by permissions).
=
Actually everything should work based on permissions which are assigned
to user. It would not be easy to implement, we need to be careful, but
if user has no permission to manage anything from Cloud Provider
section, he shouldn't see it. If user has just right to run prepared
deployables, he will see just Catalog/Catalogs from where he can launch
them, no other section from Catalog will be accessible to him, etc.
I hope it makes sense at least a little bit. In Brno, I will try to make
it more clear and explain all you wanna know. If there will still be
anything unclear, please speak up.
I am looking forward to seeing all of you.
-- 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
11 years, 5 months
Re: Re: Re: Deploying fedora infrastructure (koji) across clouds
by Mo Morsi
On 10/31/2012 01:10 PM, Seth Vidal wrote:
>
>
>
> On Wed, 31 Oct 2012, Mo Morsi wrote:
>
>>> #2: Could there be a way to take a (working) nightly build, build
>>> one's package against that nightly in a personal build of some sort,
>>> and somehow have a verification process that it built in that
>>> "personal build" before it goes into rawhide, etc? (or even... unit
>>> tests, etc.)?
>>
>> Absolutely, repositories and packages can be added on the fly, and we
>> can incorporate any image already pushed to the cloud as well as build
>> new ones for our purposes.
>
> Is this a new feature in koji, then? B/c in the past adding
> repositories has been a major limiting factor in koji. Especially
> untrusted, remote repositories.
>
Hrm I was refering more to the repos necessary to bootstrap the cloud
instance for the koji builder. Which component imposes this limitation
on koji, the hub or the builder? Would being able to build custom cloud
images on the fly for different clouds assist with this? We are able to
do that w/ our imagefactory / oz tools (written in Python incidently [1][2])
-Mo
[1] https://github.com/aeolusproject/imagefactory
[2] https://github.com/clalancette/oz
11 years, 5 months
Re: Re: Deploying fedora infrastructure (koji) across clouds
by Mo Morsi
On 10/31/2012 01:07 PM, Seth Vidal wrote:
>
>> // small wrapper script around deltacloud:
>> $ wget https://raw.github.com/movitto/mycloud/master/mycloud.rb
>> $ chmod +x mycloud.rb
>>
>> // template describing kojihub cloud deployment
>> $ wget
>> https://raw.github.com/aeolus-incubator/templates/master/fedora_infra/koj...
>>
>>
>> // template describing kojibuild cloud deployment
>> $ wget
>> https://raw.github.com/aeolus-incubator/templates/master/fedora_infra/koj...
>>
>>
>> // edit kojihub deployment to contain openstack credentials
>> $ vim koji_f17.xml
>>
>> // startup an instance on openstack w/ kojihub setup togo
>> $ ./mycloud.rb koji_f17.xml
>>
>
> Mo,
> Interesting!
>
> You can orchestrate all of these steps across/between multiple systems
> using ansible: http://ansible.cc - I've been documenting spinning up and
> provisioning instances on my blog in the last week or so. You might
> take a
> look - it should solve the problem of the above needing to be so manual
> of a process and it requires nothing other than ssh be installed on the
> machine you're trying to configure/control.
Cool thanks for the info Seth. Ansible looks interesting, its a
configuration orchestration component akin to Puppet / Chef is it not?
Does it do any provisioning in itself?
The ec2_create utility on your blog seems to call out to euca2ools to do
the actual provisioning on ec2 correct? You'd still want a component
such as Deltacloud to abstractify commands to different cloud providers
would you not?
-Mo
11 years, 5 months
Personas - shared vision for our projects
by Jiří Stránský
Hi everybody,
while I was reading the Winged Monkey thread, I realized we might be missing a key thing in our projects - some shared vision of what are we building and who are we building it for. I started reading the WM thread being sceptic and gradually moved to a point "yeah, it starts to make sense to build this thing". But I had to do a lot of thinking and read a lot of explanations before I was able to come up in my mind with ideas of concrete people who would actually want to use Winged Monkey. I think this lack of clear vision and target users causes some confusion in communication and lengthy mailing list threads where we come to a shared point of view quite slowly. I'm thinking of whole Aeolus, not just Winged Monkey.
I don't think our scrum user stories are enough to provide us with a shared point of view. They state what is the purpose of each feature, but they don't give us any idea *who* will need such thing in the first place. "As a user, I want..." is not enough, because I still don't know who is the user. And this leaves room for endless debates about whether features are needed or not.
A good tool for getting a shared point of view about a project is personas (= imaginary people who will use our product). I've seen Francesco and Justin discussing personas on IRC, but I'm not sure what was the result, so I'd like to bring them up again here. For getting familiar with personas and why they are useful I recommend reading first half of this article [1], sections "Defining Personas", "Personas as a Comminication Tool" and "Empathetic Focus". It's quite short :)
I believe that personas, when done right, would enable us to make project decisions with less friction. I believe that many of the differences in opinions are caused by the fact that each one of us has a slightly different idea of users and their use cases for Aeolus.
We could also find personas helpful when defining long-term project roadmaps.
====
An example with decision making:
Should we build APIs over network (e.g. REST) between our components, or will we just use components as Ruby gems?
1) - I don't want to put network in between our components. It makes things more complicated and there's no real benefit.
- No, it's important for connecting the components to other systems.
- Well but we still don't know if anyone will want to do that.
(... 2 hour conversation about whether external API is needed ...)
2) - Hmm, I think John, the IT infrastructure administrator in the small business company, would want to use just /this component/ and have it communicating with his /that app/.
- Hmm, so we will need some external API.
(... still far from conclusion ;) but moving forward faster ...)
The important thing is that the personas should be defined well, so that they help us with such ^^ decisions.
====
I should also admit here that personas are a lot of work and it is probably going to have to be done by someone else than me, as I have no experience with the business side of cloud computing so I have little knowledge of what users/customers might need. But "As an engineer, I'd like to have personas in order to make community decisions more effectively and efficiently" :)
Take care,
J.
[1] http://www.jnd.org/dn.mss/personas_empath.html
11 years, 5 months
