Bug 1190845

Summary:	Webadmin Re-Assignes Values for PowerManagement
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Tobias Fiebig <tfiebig>
Component:	ovirt-engine-webadmin-portal	Assignee:	Eli Mesika <emesika>
Status:	CLOSED NOTABUG	QA Contact:	Pavel Stehlik <pstehlik>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	3.5.0	CC:	ecohen, eedri, emesika, gklein, iheim, lsurette, oourfali, rbalakri, Rhev-m-bugs, tfiebig, yeylon
Target Milestone:	---
Target Release:	3.5.1
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	infra
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-02-19 15:58:17 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tobias Fiebig 2015-02-09 18:17:12 UTC

Description of problem:
When adding a custom fence-agent for powermanagement with CustomVdsFenceOptionMappings in place that overwrite configured gui-fields, manually supplied options for the original field name are moved to the mapped field.

How reproducible:

Steps to Reproduce:
1. engine-config -s CustomVdsFenceType="yyy"
2. engine-config -s CustomVdsFenceOptionMapping="yyy:port=ipport"
3. engine-config -s CustomFencePowerWaitParam="yyy=power_wait"
4. Configure powermanagement in webinterface for host
5. Leave SSH-Port field empty (which has the semantics of ipport)
6. Set options to: foo=bar,...,port=22
7. Test powermanagement (works)
8. Save the configuration
9. Re-Open the dialog to test powermanagement/try to perform a pm action

Actual results:
Power-management fails, error is "Unknown option 'ipport=22'". This is only
symptomatic, if the fencing script does not support the mapped option. However,
the underlying issue is, that the "port=22" part of the dedicated options was
parsed and entered in the field associated with the gui-element, which now has different semantics.

Expected results:
Gui/backend field for port which is (in this example) mapped to ipport retains it's original value, even if empty. The added port=22 option remains in the list of additional options.

Additional info:
This bug is rather obscure to hit, i guess. I stumbled over it while debugging #1190843. However, some other setups may also incurre this.

Comment 2 Eyal Edri 2015-02-11 12:52:59 UTC

removed 3.5.0 flag to allow tr 3.5.1, this still need a 3.5.z flag approved.

Comment 3 Eli Mesika 2015-02-19 15:31:41 UTC

I had tried the scenario and that was working perfectly...

Which agent are you using ? (in other words which agent is 'yyy')

I think that maybe you have a wrong mapping, just a wild guess , maybe you should have put "yyy:port=port" as it seems from the VDSM log that your agent does not support ipport 

please check in he list of parameters[1] and update 


[1]https://fedorahosted.org/cluster/wiki/FenceArguments

Comment 4 Tobias Fiebig 2015-02-19 15:53:13 UTC

yyy is intelmodular.

The port=port suggestion is what i finally had to do (as mentioned in #1190843).

Re-reading my bug-report i kind of feel like this is more a missunderstanding of how the different mapping conditions work, and how semantics are associated to a field on my side. So this is not-a-bug-ish.

Still, it entails a suggestion for structuring the interface and how to employ options. Would it not be possible to have "all possible options" for a fencing_script in the db, and then automatically build the interface from that?
Would be more straight-forward in my opinion... but just a suggestion, feel free to dismiss.

Comment 5 Eli Mesika 2015-02-19 15:58:17 UTC

closed per comment 4