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 <[email protected]>: > 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 < > [email protected]> 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 < >> [email protected]> 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 >>> <https://blueprints.launchpad.net/fuel/+spec/advanced-networking> 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 <[email protected]>: >>> >>> 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 <[email protected]> >>>> 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: "[email protected]" <[email protected]> >>>>> Date: Tuesday, August 26, 2014 at 2:13 PM >>>>> To: Sergii Golovatiuk <[email protected]> >>>>> Cc: "[email protected]" <[email protected]> >>>>> 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 < >>>>> [email protected]> 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 < >>>>>> [email protected]> 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 < >>>>>>> [email protected]> 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 : [email protected] >>>>>>>> Unsubscribe : https://launchpad.net/~fuel-dev >>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Mailing list: https://launchpad.net/~fuel-dev >>>>>>> Post to : [email protected] >>>>>>> Unsubscribe : https://launchpad.net/~fuel-dev >>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>> >>>>>>> >>>>>> -- Mailing list: https://launchpad.net/~fuel-dev Post to : >>>>> [email protected] Unsubscribe : >>>>> https://launchpad.net/~fuel-dev More help : >>>>> https://help.launchpad.net/ListHelp >>>>> >>>>> -- >>>>> Mailing list: https://launchpad.net/~fuel-dev >>>>> Post to : [email protected] >>>>> Unsubscribe : https://launchpad.net/~fuel-dev >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> >>>> >>>> -- >>>> Mailing list: https://launchpad.net/~fuel-dev >>>> Post to : [email protected] >>>> 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 : [email protected] >>> Unsubscribe : https://launchpad.net/~fuel-dev >>> More help : https://help.launchpad.net/ListHelp >>> >>> >> >> -- >> Mailing list: https://launchpad.net/~fuel-dev >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~fuel-dev >> More help : https://help.launchpad.net/ListHelp >> >> > > > -- > Mike Scherbakov > #mihgen > > -- Vitaly Kramskikh, Software Engineer, Mirantis, Inc.
-- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
