fuel-dev team mailing list archive

[Vitaly Kramskikh <vkramskikh@xxxxxxxxxxxx>]

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 <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.
>



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