Open Stack

Hi Liz,

thanks a lot for your feedback, I'll add some inline notes:


On 2013/02/10 20:04, Liz Blanchard wrote:

[snip]

> Hi Jarda,
>
> I just wanted to send along my feedback on the current state of the 
> Rack and Resource Class creation wireframes…
>
> *Rack Creation*
> 1) Even though it looks like with the edit icon, I think for 
> consistencies sake, we could just label the "Name" of the L-Group 
> similar to the other fields.
Yes, I agree, I already got the feedback from others and have it fixed. 
I am just working on other improvements before sending updated version 
out. Anyway, good point.

> 2) Should the "Provisioning Image" field be in line with the rest of 
> the form? It feels a bit out of place being under the add node. 
> Especially if you are adding one image for the entire L-Group.
You are adding the image only for Management Node which you are going to 
provision directly to the list of Nodes, that's why it is under the list 
of Nodes, because it relates to that.

> 3) What would you expect the "?" icon to give the user in the upper 
> right corner of the modal?
It's just quick sketch for help, I don't know yet how it will behave, I 
need to design whole helping system in forms.

> 4) I think we should denote any required fields.
Yes, I was not thinking about this at the moment, I was more focusing on 
the cencepts. Need to add it there.

> 5) Maybe we should add some sort of edit icon or link to let the users 
> know that they can edit Node settings after it's been added.
Good point.

> 6) We should allow users to remove nodes quickly after they've been 
> added. Rather than having to click on the node and then choose the 
> delete option.
Agree, I already added Edit & Remove icons to the list.

> 7) I'm not sure we need the extra "Choose Image:" text in the drop 
> down for provisioning image. Maybe you could replace the "Provisioning 
> image…" with "Choose Image"?
OK.

> 8) I think we should specify the type of node we are adding for the 
> Management Nodes. So rather than "Add Node…" it should read "Add 
> Management Node…"
For Management Node - yes, this will be very helpful.

> 9) I think the second button should read "Create and Provision" rather 
> than "Create and go to Provisioning".
It should not, because at that moment of clicking the button, you are 
going to create the l-group but you are not provisioning, you continue 
to provisioning part.

> *Resource Class Creation*
> 1) I think the "Choose Type:" should read "Class Type:".
Agree, already fixed.

> 2) I think it would be best to auto-select one of the Class types by 
> default. It feels weird to me that we wouldn't default to the first, 
> for example.
I am not sure about this, because there is no default option for user. 
There is no expectation what would be the most used option. But I will 
try to think about htat and if possible incorporate it.

> 3) We should think about how the Class Type selection scales. As users 
> are allowed to add more resource classes, maybe this selection should 
> live in a drop down to support 5-8 different classes.
This shouldn't happen. There are no other services which you can provide 
by cloud - you can provide only compute or storage services, so I don't 
expect this scaling.

> 4) I think the icons that you are used for linked vs. not linked are 
> backwards. Also, I think the lines could be removed if the values are 
> unlinked. Here is an example of what photoshop uses for if the values 
> are constrained:
> http://people.redhat.com/~lsurette/OpenStack/PS%20Link 
> <http://people.redhat.com/%7Elsurette/OpenStack/PS%20Link>
I don't think they are backwards, by default everything is unlinked. 
Dotted line helps to link the icon to the desired selection which will 
be linked then.
Anyway, this is very further future and we don't have to deal with this 
now, it won't be part of v1 or v2. We will see if users really need this 
feature and based on it we can implement it.

> 5) Similar to #7 in Rack feedback, I don't think we need the labeling 
> "Choose Property" in the drop down.
Agree.

> 6) Even though Units doesn't make sense in the example you give, I 
> think it should still be labeled "Units" and be greyed out.
Maybe. I am not very sure about this. because if I leave

> 7) How is the hardware assignment step different from the Optional 
> Provisioning step other than assigning images to the nodes? I wonder 
> if these two steps could be combined?
They shouldn't because then you go to provisioning process. It is 
different activity to assign nodes to the class or to go to node 
provisioning, it was decided to be split.

> 8) Do you think users will want to define different types of nodes 
> within one resource class? Or do you think they will want to break 
> these out into different resource classes? For example there could be 
> two types of m1.compute classes based on the hardware profile. I 
> wonder it this would make it easier to monitor and alert on these two 
> specific types of hardware? This might be something we can ask early 
> adopter users to get a feeling on how they would prefer to use classes.
Based on flexibility needs, we should allow user to assign different 
hardware to one resource class (e.g. user upgraded his hardware but 
wants to continue in providing the same service).
Resource class is more focused on provided service and the hardware 
profile information is there because we need to assure the service being 
provided correctly (SLA).

You can't have two types of m1.compute, then you will get into 2 
different compute classes where each has it's own set of flavors.

Imagine smaller deployments, where you have mixed type of hardware. And 
you want to provide compute service with 5 flavors. But because you have 
3 different vendors of each machine, you have to have 3 different 
compute classes, but providing same service. Furthermore in each you are 
specifying flavors so you will end up with 3 different sets of flavors 
in the end.

> Please let me know if you have any questions on these.
>
> Thanks,
> Liz
>
[snip]

Thanks
-- Jarda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131007/92992d6d/attachment.html>