Description of problem: Cockpit plugin (probably) takes browser language info and sends it as a locale value to the target host during HE deploy. As a result we have errors like: [ ERROR ] fatal: [localhost]: FAILED! => {"attempts": 120, "changed": true, "cmd": "virsh -r domstate \"HostedEngineLocal\"", "delta": "0:00:00.076537", "end": "2018-04-11 18:55:53.242249", "rc": 0, "start": "2018-04-11 18:55:53.165712", "stderr": "", "stderr_lines": [], "stdout": "выключен", "stdout_lines": ["выключен"]} HE can't be deployed, cause deployment tool expects phrase 'shut off' instead of "выключен", which is a russian translation for shut off. Version-Release number of selected component (if applicable): master How reproducible: Always Steps to Reproduce: 1. Configure your browser to use russian (or any other exotic language) as primary. 2. Try to install HE using cockpit. Actual results: Installation will fail randomly due to unexpectedly localized strings in tools output. Expected results: Installation should complete successfully. Additional info:
I'm not even sure that cockpit allows us to disable this. Dominik?
(In reply to Ryan Barry from comment #1) > I'm not even sure that cockpit allows us to disable this. We should just ignore the browser locale executing ansible playbooks.
We can definitely force en_us.UTF-8 The question from my side is where the localization is happening. Needs a little investigation. If cockpit itself is somehow passing pre-localized strings, it may not be possible to work around it with cockpit.spawn()
(In reply to Ryan Barry from comment #3) > The question from my side is where the localization is happening. Needs a > little investigation. Agreed. ---- Denis, I saw that you haven't tested the CLI version yet. Please update here when you've done so, so that we'll know for sure whether this is a Cockpit issue or not.
I will defer to Martin Pitt on this, but in general you shouldn't depend on browser locale when executing on the host. Example: https://github.com/cockpit-project/cockpit/blob/60b97111c5e1872d5d9e8a12358ad06272ae0362/pkg/machines/services.es6#L27
Just verified with CLI - everything went fine, so it is a cockpit issue @Ryan - that particular string definitely came from virsh, not from cockpit
*** Bug 1569372 has been marked as a duplicate of this bug. ***
1. I just saw the patch http://gerrit.ovirt.org/90491, it is related to pkg "ovirt-hosted-engine-setup". 2. Also, I tested with "ovirt-hosted-engine-setup-2.2.18" which not contain this patch, used cockpit(cockpit-ovirt-0.11.22-1), I didn't reproduce this issue. Tested version: rhvh-4.2.2.1-0.20180420.0+1 cockpit-ovirt-dashboard-0.11.22-1.el7ev.noarch ovirt-hosted-engine-setup-2.2.18-1.el7ev.noarch ovirt-hosted-engine-ha-2.2.10-1.el7ev.noarch rhvm-appliance-4.2-20180420.0.el7.noarch Test steps: 1. Set the firefox browser language to russian 2. Deploy HE via cockpit Test result: 1. Deploy HE successfully.
*** Bug 1572721 has been marked as a duplicate of this bug. ***
Works for me with these components: ovirt-hosted-engine-ha-2.2.11-1.el7ev.noarch ovirt-hosted-engine-setup-2.2.19-1.el7ev.noarch rhvm-appliance-4.2-20180427.0.el7.noarch cockpit-dashboard-165-3.el7.x86_64 cockpit-bridge-165-3.el7.x86_64 cockpit-165-3.el7.x86_64 cockpit-storaged-165-3.el7.noarch cockpit-ws-165-3.el7.x86_64 cockpit-ovirt-dashboard-0.11.23-1.el7ev.noarch cockpit-system-165-3.el7.noarch rhvh-4.2.3.0-0.20180430.0+1 Moving to verify. It works well for me. If also meet this issue with these component or newer than them, please reopen it.
Sorry for the late reply! https://gerrit.ovirt.org/gitweb?p=ovirt-hosted-engine-setup.git;a=commitdiff;h=84b8b4d16b391f6 looks okay to me. A nitpick would be that en_US.UTF-8 might not strictly be relied upon everywhere, but in pretty much every practical case it is (and particularly in Fedora and RHEL). But if it is really not available, it will just fall back to using C. But a better choice these days is C.UTF-8. Thanks!
This bugzilla is included in oVirt 4.2.3 release, published on May 4th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.3 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.