Bug 1402796

Summary: machine dialect sends invalid format of QValidValues keyword
Product: [oVirt] otopi Reporter: Lukas Bednar <lbednar>
Component: Plugins.dialogAssignee: Yedidyah Bar David <didi>
Status: CLOSED CURRENTRELEASE QA Contact: Nikolai Sednev <nsednev>
Severity: high Docs Contact:
Priority: high    
Version: 1.5.2CC: bugs, didi, lbednar, lsvaty, rbarry, ylavi
Target Milestone: ovirt-4.2.0Keywords: AutomationBlocker, Triaged
Target Release: 1.7.2Flags: ylavi: ovirt-4.2+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-12-20 11:46:51 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Integration RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Lukas Bednar 2016-12-08 11:18:54 UTC 
Description of problem:

machine dialect sends '***QValidValues' instead of '**QValidValues'.
Documentation says that it should have double asterisk, but client gets triple.

Version-Release number of selected component (if applicable):
otopi-1.5.2-1.el7ev.noarch


How reproducible:
100%

Steps to Reproduce:
1. start deployment for HE with machine dialect.
2. and see the format of given QValidValues, you can see triple asterisk instead of double.

Actual results:

for example the OVEHOSTED_STORAGE_DOMAIN_TYPE option posses:

'***QValidValues: glusterfs|iscsi|fc|nfs3|nfs4'

Expected results:

'**QValidValues: glusterfs|iscsi|fc|nfs3|nfs4'

Additional info:

there is already fix for that which appears in rhv-4.1. but we need it for rhv-4.0 as well.
Comment 1 Yedidyah Bar David 2016-12-08 11:20:42 UTC 
Ryan, is this safe to change also in 4.0?
Comment 2 Ryan Barry 2016-12-08 13:06:55 UTC 
The cockpit UX redesign got pushed to 4.2, so we're not using this parser code in cockpit yet. Feel free to change.
Comment 3 Yedidyah Bar David 2017-07-20 11:58:44 UTC 
Sorry I didn't handle it at the time.

Is it still relevant, now that 4.1 is out?
Comment 4 Lukas Bednar 2017-07-21 06:55:42 UTC 
I don't know whether it is relevant or not, but for sure there is bug in that protocol.

As far as I know we stopped to use otopi-machine-dialect for deploying hosted-engine, at least for 4.1+ . So it doesn't block us at this moment.
Comment 5 Yedidyah Bar David 2017-10-16 12:01:32 UTC 
For 4.2, nothing else needed.
Comment 6 Nikolai Sednev 2017-11-01 03:56:46 UTC 
Can you please explain what does it mean exactly "start deployment for HE with machine dialect"?
Comment 7 Yedidyah Bar David 2017-11-01 07:04:36 UTC 
(In reply to Nikolai Sednev from comment #6)
> Can you please explain what does it mean exactly "start deployment for HE
> with machine dialect"?

Do one of:

1. Start HE deploy from cockpit - it always uses the machine dialect

2. Run manually: hosted-engine --deploy --otopi-environment="DIALOG/dialect=str:machine"
Comment 8 Nikolai Sednev 2017-11-01 09:34:00 UTC 
Works for me on ovirt-hosted-engine-setup-2.2.0-0.0.master.20171016160008.git55723e8.el7.centos.noarch:

### Please specify the storage you would like to use (glusterfs, iscsi, fc, nfs3, nfs4)[nfs3]: 
**%QDefault: nfs3
**%QValidValues: glusterfs|iscsi|fc|nfs3|nfs4
Comment 9 Sandro Bonazzola 2017-12-20 11:46:51 UTC 
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017.

Since the problem described in this bug report should be
resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.