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