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.
removed 3.5.0 flag to allow tr 3.5.1, this still need a 3.5.z flag approved.
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
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.
closed per comment 4