A few quick notes. Flavors need their extra attributes to be editable (e.g. architecture, raid config etc) - particularly in the undercloud, but it's also relevant for overcloud : If we're creating flavors for deployers, we need to expose the full capabilities of flavors.
Secondly, if we're creating flavors for deployers, the UI should reflect that: is it directly editing flavors, or editing the inputs to the algorithm that creates flavors. We seemed to have consensus @ the sprint in Seattle that Racks aren't really Racks : that is that Rack as currently defined is more of a logical construct (and some clouds may have just one), vs the actual physical 'This is a Rack in a DC' aspect. If there is a physical thing that the current logical Rack maps too, perhaps we should use that as the top level UI construct? The related thing is we need to expose the other things that also tend to map failure domains - shared switches, power bars, A/C - but that is future work I believe. The 'add rack' thing taking a list of MACs seems odd : a MAC address isn't enough to deploy even a hardware inventory image to (you need power management details + CPU arch + one-or-more MACs to configure TFTP and PXE enough to do a detailed automatic inventory). Long term I'd like to integrate with the management network switch, so we can drive the whole thing automatically, but in the short term, I think we want to drive folk to use the API for mass enrollment. What do you think? Regardless, the node list will need to deal with nodes having N MAC addresses and management credentials, not just a management IP. Lastly, whats node name for? Instances [may] have names, but I don't see any reason for nodes to have a name. Similarly, it's a little weird that racks would have names. CSV uploads stand out to me as an odd thing: JSON is the standard serialisation format we use, does using CSV really make sense? Tied into that is the question above - does it make sense to put bulk enrollment in the web UI at all, or would it be better to just have prerolled API scripts for that? Having 'upload racks' etc as a UI element is right in the users face, but will be used quite rarely. I don't follow why racks would be bound to classes: class seems to be an aspect of a specific machine + network capacity configuration, but Rack is a logical not physical construct, so it's immediately decoupled from that. Perhaps it's a keep-it-simple thing, which I can get behind - but in that case, reducing the emphasis on Rack / renaming Rack becomes more important IMO. HTH, Rob -Rob On 25 September 2013 09:03, Jaromir Coufal <jcou...@redhat.com> wrote: > Hey folks, > > I want to introduce our direction of Tuskar UI, currently described with POC > wireframes. Keep in mind, that wireframes which I am sending were made for > purpose of proof of concept (which was built and released in August) and > there are various changes since then, which were already adopted. However, > basic concepts are staying similar. Any updates for wireframes and future > direction will be sent here to the dev-list for feedback and reviews. > > http://people.redhat.com/~jcoufal/openstack/tuskar/2013-07-11_tuskar_poc_wireframes.pdf > > Just quick description of what is happening there: > * 1st step implementation - Layouts (page 2) > - just showing that we are re-using all Horizon components and layouts > * Where we are heading - Layouts (page 8) > - possible smaller improvements to Horizon concepts > - majority just smaller CSS changes in POC timeframe scope > * Resource Management - Flavors (page 15) - ALREADY REMOVED > - these were templates for flavors, which were part of selection in > resource class creation process > - currently the whole flavor definition moved under compute resource > class completely (templates are no longer used) > * Resource Management - Resources (page 22) > - this is rack management > - creation workflow was based on currently obsolete data (settings are > going to be changed a bit) > - upload rack needs to make sure that we know some standard csv file > format (can we specify some?) > - detail page of rack and node, which are going through enhancement > process > * Resource Management - Classes (page 40) > - resource class management > - few changes will happen here as well regarding creation workflow > - detail page is going through enhancements as well as racks/nodes > detail pages > * Graphic Design > - just showing the very similar look and feel as OpenStack Dashboard > > If you have any further questions, just follow this thread, I'll be very > happy to answer as much as possible. > > Cheers, > -- Jarda > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
