Re: [openstack-dev] [Tuskar] [UI] Introducing POC Wireframes
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
Re: [openstack-dev] [Tuskar] [UI] Introducing POC Wireframes
Hi Rob, thank you very much for such valuable feedback, I really appreciate it. Few comments follow inline the text. On 2013/25/09 03:50, Robert Collins wrote: 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. ad extra attributes: Until now for POC we were dealing only with flavor definition values and no extra attributes. Can you be please a bit more descriptive about extra attributes or at least point me to some documentation for it (for undercloud as well as overcloud flavors)? Flavors in the Tuskar UI is for deployers and it is a definition for the algorithm that registers flavors in nova after a machine is provisioned. 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? Well in ideal case we represent physical thing with logical grouping of nodes. In this case we are able to operate with hardware in the most efficient way. Of course we might end up that this is not reality and we need to support it in the UI as well. But I don't think I follow the idea with rack being the top level UI construct. I think this depends on the point of view how you are looking at the deployment. I think there are 2 ways of how deployer wants to see his deployment: 1) Hardware focus. Deployer is interested if his hardware is running fine and everything is running correctly. In this case you are right - the top level should be rack and it is rack in this moment. 2) Service focus. Deployer is interested what service is he providing, how much capacity he has available, left, in capacity planning, etc. For this purpose we have resource classes, which are defining what service you (as deployer) provide to your customers/users. 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. In general I don't think that it is good idea to replicate other applications for DC monitoring, which already exist and we would only put effort to their duplication. I mean if we can get general information about switches, etc, yes that would be great, but I would recommend to make distinction between deployment management and DC monitoring. 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? So for the short term we were counting with some sort of auto-discovery which means with minimal input from user PXE boot some minimal image, do the introspection of the machine and fill all the details for user. But you are right, that only MAC address isn't enough. What I think will be needed are power management credentials (currently support for IPMI - so the MAC address /or IP/, IPMI username and IPMI password). I believe all other information can be introspected (in short term). 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. I believe that node name will be mac address by default (in majority cases). There was idea about having possibility to rename the node for deployers' needs if they need better recognition. Let's imagine that we have a rack with mixed hardware, each node running different services, if we rename those few nodes with for example name of services they are running (or any purpose they are doing), then for the first glance, I as deployer have better overview about what my rack contains and where it is located. Do you see the use case there? Similarly, it's a little weird that racks would have names. Similar situation as nodes above. 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
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 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
Re: [openstack-dev] [Tuskar] [UI] Introducing POC Wireframes
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.pdfhttp://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.orgmailto: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
[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 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
Re: [openstack-dev] [Tuskar] [UI] Introducing POC Wireframes
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 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
