Bug 1144649

Summary:	Fencing UI on host edit form has some bugs
Product:	Red Hat OpenStack	Reporter:	Scott Seago <sseago>
Component:	rubygem-staypuft	Assignee:	Imre Farkas <ifarkas>
Status:	CLOSED ERRATA	QA Contact:	Omri Hochman <ohochman>
Severity:	high	Docs Contact:
Priority:	high
Version:	5.0 (RHEL 7)	CC:	aberezin, athomas, mburns, oblaut, ohochman, sasha, yeylon
Target Milestone:	z1	Keywords:	ZStream
Target Release:	Installer
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	ruby193-rubygem-staypuft-0.3.8-1.el6ost	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1146463 (view as bug list)		Environment:
Last Closed:	2014-10-02 12:56:35 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1142873, 1146463

Description Scott Seago 2014-09-20 04:47:26 UTC

Description of problem:
Fencing UI on host edit form has some bugs

Version-Release number of selected component (if applicable):
0.3.6

How reproducible:
Always

Steps to Reproduce:
1. Go to the edit view on the host
2. Try to use the Fencing Tab

Actual results:
1) if fencing is set to disabled, none of the fields entered are processed, even the 'fencing enabled?' one -- so once fencing is enabled, it's impossible to disable it
2) The form lets me enable fencing without selecting a fencing type
3) after submitting, on edit, there doesn't seem to be any code that pre-populates the form with the current values
4) It's not clear whether field validation is handled here
5) It's also not clear whether the alternate disabled UI shows up if there's no bmc nic

Expected results:
1) Submitting the form with "fencing enabled" checkbox un-selected should disable fencing
2) Fencing type should be required if enabled
3) After submitting once, previously-entered values should show up in the form on edit.
4) Errors in field entry should show up like standard form validation UI
5) If the host has no BMC nic, the alternate "disabled" view should appear

Comment 3 Imre Farkas 2014-09-23 11:29:19 UTC

PR: https://github.com/theforeman/staypuft/pull/313

Comment 4 Imre Farkas 2014-09-23 13:49:28 UTC

Merged: https://github.com/theforeman/staypuft/commit/9a3554c35ba12569b0e0c0b574127a6535856794

Comment 6 Omri Hochman 2014-09-24 08:44:50 UTC

Cannot enable fencing using :ruby193-rubygem-staypuft-0.3.9-1.el6ost.noarch

When selecting the 'Enable Fencing' check box and entering values in the other fencing fields, All those changes won't remain after clicking the 'Submit' button and trying to edit the fencing tab again - it will show fencing disable and the fencing values are empty.

Comment 7 Imre Farkas 2014-09-24 09:30:43 UTC

Omri, could you please provide me an access to an environment where I can reproduce this isse? It works for me locally.

Comment 8 Imre Farkas 2014-09-24 12:28:09 UTC

The issue seems to be caused by forgot to add a BMC interface to the Host. This is expected behavior in that case.

There's a different issue here, that in case there's no BMC interface, the fencing form should be disabeld. It is done by js, which doesn't seem to be loaded with the page.

Comment 9 Alexander Chuzhoy 2014-09-24 17:49:58 UTC

Verified:rhel-osp-installer-0.3.6-1.el6ost.noarch


Went through the result/expected result: 
Wasn't sure about the expected result #4:  Errors in field entry should show up like standard form validation UI). Understood that the bug was opened for specific fields and these issues are gone.
Submitted another bug for validating other fields #1146189.

The other reported issues are fixed.

Comment 10 Imre Farkas 2014-09-25 10:14:58 UTC

There shouldn't be any validation on those fields as they are just copied from the BMC interface. Username and password input fields on the fencing form should be binded to the input field of the BMC interface but there's a issue with the javascript file which implements it. Check #1146463.

Comment 11 Scott Lewis 2014-10-02 12:56:35 UTC

Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1350.html