Open Stack

Hardware profile itself is just one part of a 'resource class', another 
part is service specification (flavors for compute, might be some 
additional settings for storage). Maybe something a bit more general? 
Soon, I'll send wireframes for updated class creation workflow, where it 
might be better visible, what are the parts of 'resource class'.

-- Jarda


On 2013/25/09 21:46, Gabriel Hurley wrote:
>
> After reading your description in the other email, I might suggest the 
> term “hardware profile” instead of “class”. Just a thought.
>
> -Gabriel
>
> *From:*Jaromir Coufal [mailto:jcoufal at redhat.com]
> *Sent:* Wednesday, September 25, 2013 6:11 AM
> *To:* OpenStack Development Mailing List
> *Cc:* Gabriel Hurley
> *Subject:* Re: [openstack-dev] [Tuskar] [UI] Introducing POC Wireframes
>
> Hi Gabriel,
>
> thanks for follwoing this thread and having a look on wireframes. 
> Regarding the term 'resource class', the naming is what we got into 
> during our initial intents. It's not final version, so if there are 
> concerns, there is no problem in finding more accurate one (we just 
> couldn't find better). As for resource class definition, I tried to 
> explain it a bit more in reply to Rob's mail (in this thread), so if 
> you get that one, I hope it will help to answer and explain the 
> concept of classes a little bit more.
>
> If you still have any concerns, let me know I will try to be more 
> explicit.
> -- Jarda
>
> On 2013/25/09 02:03, Gabriel Hurley wrote:
>
>     Really digging a lot of that. Particularly the
>     inter-rack/inter-node communication stuff around page 36ish or so.
>
>     I’m concerned about using the term “Class”. Maybe it’s just me as
>     a developer, but I couldn’t think of a more generic, less
>     inherently meaningful word there. I read through it and I still
>     only vaguely understand what a “Class” is in this context. We
>     either need better terminolody or some serious documentation/user
>     education on that one.
>
>     Also, I can’t quite say how, but I feel like the “Class” stuff
>     ought to be meshed with the Resource side of things. The
>     separation seems artificial and based more on the API structure
>     (presumably?) than on the most productive user flow when
>     interacting with that system. Maybe start with the question “if
>     the system were empty, what would I need to do and how would I
>     find it?”
>
>     Very cool though.
>
>     -Gabriel
>
>     *From:*Jaromir Coufal [mailto:jcoufal at redhat.com]
>     *Sent:* Tuesday, September 24, 2013 2:04 PM
>     *To:* OpenStack Development Mailing List
>     *Subject:* [openstack-dev] [Tuskar] [UI] Introducing POC Wireframes
>
>      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
>     <http://people.redhat.com/%7Ejcoufal/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  <mailto:OpenStack-dev at lists.openstack.org>
>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130926/e9aed5a8/attachment.html>