Open Stack

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 <jcoufal at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud