fuel-dev team mailing list archive

[Vitaly Kramskikh <vkramskikh@xxxxxxxxxxxx>]

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.