fuel-dev team mailing list archive

[Dmitry Borodaenko <dborodaenko@xxxxxxxxxxxx>]

On Wed, Apr 2, 2014 at 1:58 AM, Vitaly Kramskikh
<vkramskikh@xxxxxxxxxxxx> wrote:
> As for hypervisor configuration, we decided to make a separate screen for
> it. It should be like screens for disks and interfaces configuration. It is
> needed to configure nodes in batch, as we decided that this functionality is
> essential. To avoid yet another button on node configuration panel, we
> decided to move all batch actions under a dropdown.

What is the dropdown going to look like? Do you have any mockups /
whiteboard snaps?

> As for running network verification before deployment, we decided to add a
> checkbox in the deployment confirmation dialog. We decided not to add
> deployment/provision checkboxes as it was proposed before, as
> deployment/provisioning separation feature is not supposed to be used from
> UI. If network verification fails, deployment won't be started. But if user
> is sure that his network configuration is ok, he can uncheck and deployment
> will be started without network checks.

+1

> As for nodes network configuration invalidation after network settings
> change, there were 2 ideas about how we can warn a user:
>
> After network configuration is saved, show a table with a list of nodes with
> invalid configuration with links to interfaces configuration.

-1: We already have a page with a list of nodes, lets reuse that as per below.

> After network configuration is saved, show a simple warning that
> configuration for some nodes it not valid anymore and somehow highlight
> these nodes in the list of nodes, so user could know which nodes should be
> reconfigured. This approach seems to be better because of batch interface
> configuration can be used to reconfigure nodes.

+1

> As for ability not to partition chosen disks and write boot sector on them
> there were 2 ideas:
>
> Don't touch disk at all if user left all disk space unallocated. Every
> partitioned drive will have boot sector. No UI modifications required.

+1

> Return "make bootable" checkbox for every disk so user can manually mark
> disks which he wants to make bootable.

Eventually we'll need this option, too.

For example, according to this:
http://www.openstack.org/assets/presentation-media/Swift-at-Scale.pdf

RackSpace has 90 drives per storage node. We need to allow user to
partition 90 OSD drives without creating a RAID1 boot partition across
all of them.

My 2c,

-- 
Dmitry Borodaenko