On Wed, Apr 2, 2014 at 9:54 PM, Dmitry Borodaenko <[email protected]>wrote:
> On Wed, Apr 2, 2014 at 1:58 AM, Vitaly Kramskikh > <[email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~fuel-dev > More help : https://help.launchpad.net/ListHelp > -- Mike Scherbakov #mihgen
-- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
