On Sep 30, 2013, at 5:07 PM, Jaromir Coufal <[email protected]> wrote:
> Just BTW: > > I know that lot of folks were watching the youtube stream > (http://youtu.be/m3y6uD8yKVQ), so please feel free to give any feedback you > have to this thread. I believe that this is good way to proceed forward and > how to make things flexible enough to support various types of deployments. > > Looking forward to any feedback 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. 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. 3) What would you expect the "?" icon to give the user in the upper right corner of the modal? 4) I think we should denote any required fields. 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. 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. 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"? 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…" 9) I think the second button should read "Create and Provision" rather than "Create and go to Provisioning". Resource Class Creation 1) I think the "Choose Type:" should read "Class Type:". 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. 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. 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 5) Similar to #7 in Rack feedback, I don't think we need the labeling "Choose Property" in the drop down. 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. 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? 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. Please let me know if you have any questions on these. Thanks, Liz > > Thanks > -- Jarda > > On 2013/30/09 13:57, Jaromir Coufal wrote: >> Hi everyone, >> >> based on Tuskar's merger with TripleO and upstream feedback on Tuskar, when >> I was thinking about processes and workflows there, I got into some changes >> which I think that are important for us, because they will help us to >> achieve better flexibility and still having ability for easy scaling. >> >> I wanted to do just walkthrough the wireframes but I think that it will >> raise up some discussion around Classes and Racks, so my thought was to >> merge both together (wireframes + concepts discussion). >> >> At this meeting I'd like to get you familiar with my thoughts and get into >> some wireframes which will explain the ideas more. I hope that we will get >> into discussion around changes (not just UI but API as well). >> >> The scope which we will be talking about is Icehouse. >> >> I'll be posting link into #tripleo IRC channel. >> I'd like to record the whole session, so if anybody cannot attend, it should >> be available for you later. >> >> (Please note that Google Hangout has limited number of 10 participants, so >> if you consider just watching, please use youtube stream - link will be >> posted here when available.) >> >> Thanks >> -- Jarda >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
