Hide Forgot
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.
Ryan, is this safe to change also in 4.0?
The cockpit UX redesign got pushed to 4.2, so we're not using this parser code in cockpit yet. Feel free to change.
Sorry I didn't handle it at the time. Is it still relevant, now that 4.1 is out?
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.
For 4.2, nothing else needed.
Can you please explain what does it mean exactly "start deployment for HE with machine dialect"?
(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"
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
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.