Folks, I did a lot of updating mockups for real screens which will be new look of Fuel UI https://docs.google.com/a/mirantis.com/document/d/1O2G-fTXlEWh0dAbRCtbrFtPVefc5GvEEOhgBIsU_eP0/edit#heading=h.bsjcv2hdpa3
-- Bogdan Dudko На 3 сентября 2014 в 19:34:51, Vitaly Kramskikh (vkramsk...@mirantis.com) написал: Folks, Step 7 (disk configuration) was updated with a new mockup: https://docs.google.com/a/mirantis.com/document/d/1O2G-fTXlEWh0dAbRCtbrFtPVefc5GvEEOhgBIsU_eP0/edit The main idea here is to group all the nodes by not just by physical drives, but also by disk allocation. Disk allocation will be same by the beginning of configuration, but is is possible to choose arbitrary nodes in a group by clicking the checkboxes and change allocation. As disk allocation for some nodes is changed, a new group will be created. So in every such a group physical drives and disk allocation are identical. 2014-09-01 18:10 GMT+07:00 Vitaly Kramskikh <vkramsk...@mirantis.com>: I've created a document for convenient commenting: https://docs.google.com/a/mirantis.com/document/d/1O2G-fTXlEWh0dAbRCtbrFtPVefc5GvEEOhgBIsU_eP0/edit 2014-09-01 16:39 GMT+07:00 Mike Scherbakov <mscherba...@mirantis.com>: Folks, it becomes hard to follow opinions regarding different steps in wizard, so I've requested Vitaly to create a google doc with separate steps, so we can discuss step by step - and not to mess everything in one email. Conceptually, > - display our normal UI after the wizard, so that users can review/edit >configs before deployment (I.e. wizard doesn't replace the normal UI) I strongly against this, and in a full support of Vitaly's opinion expressed in his email. > that users can review/edit configs before deployment it would be fully possible with wizard interface. Roman, let us know if you see any specific issue with wizard which you want to cover with "normal UI" (I believe you mean tab-based, or some other UI form - but not wizard like). Thanks, On Thu, Aug 28, 2014 at 2:27 AM, Dmitriy Novakovskiy <dnovakovs...@mirantis.com> wrote: Vitaly, Thanks a lot for clarification. I definitely like the direction we're moving in. A few more thoughts: Cluster type - maybe i'm missing something in this idea, but I really don't understand why we might want to implement anything of that kind. 99% percents of MOS/Fuel deployments are "general purpose" clouds, I've seen very few "Storage-only" cases, no other candidates for "typization" so far. IMO it may make sense later to introduce "OpenStack for Hadoop", "OpenStack for Storage", "OpenStack for XYZ" scenarios, but only after careful consideration of how many users will actually benefit from it. Also, this will be possible only at point when Fuel will allow "assembling" OpenStack clusters in declarative+amending manner - "Ok, here are my controllers. Now I add a pool of KVM nodes and form AZ1. Then I add a pool of ESXi nodes and for AZ2. Finally, I add a pool of Ironic nodes and call them AZ3-Hadoop". Again, I may be missing the point. Terminology. We're ultra-inconsistent - environment, cluster, cloud... I would suggest cleaning up everything altogether and leaving single definition - "cloud" . Network settings - As I earlier suggested, the wizard must not impose default values for ip ranges and VLAN id's, and should explicitly ask users to enter real values (incl. addresses for default logical networks that will be created after "advanced-networking" is in place) --- Regards, Dmitriy Novakovskiy Sales Engineer, Mirantis EMEA Skype: dmitriy.novakovskiy Operating from: Ukraine On Wed, Aug 27, 2014 at 7:20 PM, Vitaly Kramskikh <vkramsk...@mirantis.com> wrote: Thank you a lot for your feedback! Dmitriy, Ok, as single-node disk configuration is essential, we'll make another proposal for this step. I think it could look the same as it is implemented now (manually select nodes and click a button). As for separation of network configuration and network check steps, I think they should be separated as these mockups don't have interface configuration step (it would resemble disk configuration step) and after implementation of advanced networking blueprint there will be even more network-related steps. And I also think it is a good idea to verify networks after configuration by default (users can skip this step or ignore verification results if they want). Cluster settings screen will contain settings that are currently located at the settings tab. Cluster type screen would ask the user which type cluster he/she wants and what additional services should be installed. Then nailgun will try to automatically assign the roles according to this choice. These roles can be reassigned on the next step. Sergii, Is it possible to configure these pools now on our UI? Can this configuration be made via the settings step or it requires additional step? Roman, Yes, our current tabbed UI will be displayed after completion of the wizard as there are tabs that doesn't fit into wizard (actions, logs, ostf). But I'm afraid we cannot remove "Deploy" step from the wizard or we need to make tabbed UI readonly. One of the main reasons we've started to think about our UI overhaul is that there are more and more dependencies between tabs which are really difficult to track and changes on one tab can lead to inconsistency on others. Examples in the current UI: Disk configuration depends on node's roles and if it is changed, disk configuration is reset to default. We only warn the user if he/she tries to do that. Some options on the settings tab depend on current role set (ceph, ceilometer/mongo). It is difficult to validate these dependencies in both places as the user can do modifications at the nodes tab and the settings tab. After these modifications settings can become inconsistent (for example, the user can provide valid Ceph replication factor and then go and delete some ceph nodes). Currently the user can configure interfaces properly and then remove tags from some networks and interface configuration becomes invalid. All the stuff above is really minor in comparison with the nightmare we're going to have when we have advanced networking implemented. There lots of dependencies and we have to somehow track them or reset configuration to default on change of roles or settings. But it fits really well in the wizard, just like similar features like RAID configuration, etc. We had to disable some stuff like ability to change release or network manager on created cluster for the same reason. These changes could be easily performed in the wizard. In the wizard we define the order of the steps and know which step depends on which and there would be only "one-way dependencies" couldn't be any inconsistencies of that kind. User can go back to one of the previous steps and make required changes and if it conflicts with the data entered in the next steps, these next steps will be reset and marked as incomplete. You can see how it works in the current "small" cluster creation wizard. If you decide to create a cluster with Neutron, go to Additional Services step, check Murano and then decide to change network manager to nova-network, steps after the Network step will be marked as incomplete. But if you go back and change Cinder storage to Ceph, nothing will be reset as there are no dependencies on storage in the next completed steps. We could reuse this algorithm in the new "big" wizard. David, As for screen #1, I think we could show the latest releases only for each operation system. As for screen #7, maybe it is, but as I said above, all the configuration will only be done through this wizard. So current disk configuration screen will be just moved to the wizard. 2014-08-27 21:41 GMT+07:00 Aleksey Kasatkin <akasat...@mirantis.com>: Hi, There is no networks-to-interfaces configuration on screens #5 & #6 but it is obligatory for manual setup as we cannot distribute networks automatically. We make default networks-to-interfaces assignment but we don't have enough info to assume how close is it to user requirements. So, I propose to have this configuration in Wizard. Aleksey Kasatkin On Wed, Aug 27, 2014 at 1:41 AM, David Easter <deas...@mirantis.com> wrote: Here’s my feedback. First off, thanks for kicking off this effort. Always good to see initiative to improve the product and user experience specifically. Screen #1 – would like to see how it will look when there are multiple versions – e.g. 2014.1.1-5.1, 2014.1.3-5.1.1, 2014.1.4-5.1.2, etc. Will the button activate a pulldown? Screen #3 – I like the general idea of “pre-defined templates” for cluster types – we'll need to be good definition for the purpose of the template. Compute is the obvious one (just controllers + compute nodes). The others we’ll need to think about in terms of pre-defined distribution of roles. Screen #4 - should reflect the choices from Screen #3 – I.e. if I picked “Compute” as the template, then it should show by default the nodes already assigned (one controller, the rest computes). Perhaps that is what you’re showing here already. Screen #5 & 6 combined - +1. Also, the defaults should be put in if possible. The idea for a wizard is that your simplest user who doesn’t want to make any config changes can just click through taking the defaults without having to think too much. We don’t want to make this too advanced and force the user to go look up stuff in doc or ask someone else what to enter. Screen #7 - seems to be a bit complex for a wizard. Screen #8 – I like this if it enables advanced windows to pop up when the buttons are pushed. Again, this allows someone to click through without changes but makes it available advanced users in a more convenient manner. Screen #9 – I like that you can deploy immediately from here, but agree with Roman that there should be also an option to display the normal UI after the wizard in case even more advanced things need to be done or to double check everything before deploying. Thanks! -Dave Easter From: "ralekseen...@mirantis.com" <ralekseen...@mirantis.com> Date: Tuesday, August 26, 2014 at 2:13 PM To: Sergii Golovatiuk <sgolovat...@mirantis.com> Cc: "fuel-dev@lists.launchpad.net" <fuel-dev@lists.launchpad.net> Subject: Re: [Fuel-dev] Disk configuration UI in the new environment creation wizard +1 for combining network setup & verification -1 for disks. individual configuration of nodes should be allowed Also I'm not sold on #3. Is there a point in asking about additional services upfront? All of that can come later (cluster settings). And separation between compute/storage/c+s --- why are we asking for it? I would also: - remove deploy step from the wizard - display our normal UI after the wizard, so that users can review/edit configs before deployment (I.e. wizard doesn't replace the normal UI) All in all, I like the look and feel. Great job! Thanks, Roman On Tuesday, August 26, 2014, Sergii Golovatiuk <sgolovat...@mirantis.com> wrote: Hi, There should be separate step for Ceph, as ceph may have SSD+HDD pools or more advanced configurations. ~Sergii -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Tue, Aug 26, 2014 at 8:12 PM, Dmitriy Novakovskiy <dnovakovs...@mirantis.com> wrote: Hi Vitaly, Most frequent use cases from disk config perspective are: A) Ceph storage (dedicated nodes) - your approach works fine, nodes are recommended to be uniform B) LVM storage (dedicated or co-located w/ Compute nodes) - storage configuration is per-node, your approach doesn't work C) Enterprise SAN/NAS - disk config is mostly irrelevant Leaving per-node configuration in CLI only is not good - it will limit trial/pilot/playing around users. I would suggest exposing group configuration on main screen with all nodes list as default option, allowing individual node's config to be reachable via individual node's HW screen. --- Regards, Dmitriy Novakovskiy Sales Engineer, Mirantis EMEA Skype: dmitriy.novakovskiy Operating from: Ukraine On Tue, Aug 26, 2014 at 6:58 PM, Vitaly Kramskikh <vkramsk...@mirantis.com> wrote: Hi folks, As you may know, there are some activities aimed to improve environment creation UX and create a single wizard that will guide a user from the very environment creation to the start of deployment. There are some mockups that show how it could look like: https://docs.google.com/file/d/0B2iuEqmr4C0uczBRbDZkc1Uxek0/edit I want to ask a question about step #7 (disk configuration). There would be a list of nodes automatically grouped by roles+disks, so disks of all the nodes in a group can be configured at once. I think this approach is better than the current one (group nodes by hardware, check nodes/groups, click "Configure Disks" button) for large environments with homogeneous nodes, but we'll lose the ability to configure disks of an arbitrary group of nodes or a single node. The question is: is this functionality really needed? Maybe it should be available via CLI only? What is your opinion? -- Vitaly Kramskikh, Software Engineer, Mirantis, Inc. -- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp -- Vitaly Kramskikh, Software Engineer, Mirantis, Inc. -- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp -- Mike Scherbakov #mihgen -- Vitaly Kramskikh, Software Engineer, Mirantis, Inc. -- Vitaly Kramskikh, Software Engineer, Mirantis, Inc. -- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
-- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
