fuel-dev team mailing list archive
-
fuel-dev team
-
Mailing list archive
-
Message #00774
Re: UI/Nailgun integration meeting notes
On Wed, Apr 2, 2014 at 9:54 PM, Dmitry Borodaenko
<dborodaenko@xxxxxxxxxxxx>wrote:
> 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
>
What would be the error message if net-verify fails? how can we redirect
user to the info about issue, e.g. table with VLAN numbers not passed
through switch?
>
> > 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.
>
Only if it's enabled by default. Otherwise users won't be enabling it, and
thus failing to boot a node.
>
> 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
>
> --
> 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
Follow ups
References