fuel-dev team mailing list archive

[Vitaly Kramskikh <vkramskikh@xxxxxxxxxxxx>]

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 <mscherbakov@xxxxxxxxxxxx>:

> 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 <
> dnovakovskiy@xxxxxxxxxxxx> 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 <
>> vkramskikh@xxxxxxxxxxxx> 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 <akasatkin@xxxxxxxxxxxx>:
>>>
>>> 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 <deaster@xxxxxxxxxxxx>
>>>> 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: "ralekseenkov@xxxxxxxxxxxx" <ralekseenkov@xxxxxxxxxxxx>
>>>>> Date: Tuesday, August 26, 2014 at 2:13 PM
>>>>> To: Sergii Golovatiuk <sgolovatiuk@xxxxxxxxxxxx>
>>>>> Cc: "fuel-dev@xxxxxxxxxxxxxxxxxxx" <fuel-dev@xxxxxxxxxxxxxxxxxxx>
>>>>> 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 <
>>>>> sgolovatiuk@xxxxxxxxxxxx> 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 <
>>>>>> dnovakovskiy@xxxxxxxxxxxx> 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 <
>>>>>>> vkramskikh@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>>>>>>>> Unsubscribe : https://launchpad.net/~fuel-dev
>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Mailing list: https://launchpad.net/~fuel-dev
>>>>>>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>>>>>> Unsubscribe : https://launchpad.net/~fuel-dev
>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>>
>>>>>> -- Mailing list: https://launchpad.net/~fuel-dev Post to :
>>>>> fuel-dev@xxxxxxxxxxxxxxxxxxx Unsubscribe :
>>>>> https://launchpad.net/~fuel-dev More help :
>>>>> https://help.launchpad.net/ListHelp
>>>>>
>>>>> --
>>>>> Mailing list: https://launchpad.net/~fuel-dev
>>>>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~fuel-dev
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>
>>>> --
>>>> Mailing list: https://launchpad.net/~fuel-dev
>>>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>>> 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@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~fuel-dev
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> --
>> Mailing list: https://launchpad.net/~fuel-dev
>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~fuel-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> Mike Scherbakov
> #mihgen
>
>


-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.