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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
