Bug 1566162 - Cockpit plugin should never use browser's locale
Summary: Cockpit plugin should never use browser's locale
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: cockpit-ovirt
Classification: oVirt
Component: Hosted Engine
Version: 0.11.20
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ovirt-4.2.3
: ---
Assignee: Phillip Bailey
QA Contact: Yihui Zhao
URL:
Whiteboard:
: 1569372 1572721 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-11 16:08 UTC by Denis Chaplygin
Modified: 2018-05-10 06:32 UTC (History)
10 users (show)

Fixed In Version: cockpit-ovirt-0.11.23-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-10 06:32:16 UTC
oVirt Team: Integration
rule-engine: ovirt-4.2+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 90491 0 master MERGED ansible: enforce external command locale 2018-09-03 09:33:31 UTC
oVirt gerrit 90496 0 ovirt-hosted-engine-setup-2.2 MERGED ansible: enforce external command locale 2018-04-20 15:00:08 UTC

Description Denis Chaplygin 2018-04-11 16:08:03 UTC
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:

Comment 1 Ryan Barry 2018-04-11 16:12:59 UTC
I'm not even sure that cockpit allows us to disable this.

Dominik?

Comment 2 Simone Tiraboschi 2018-04-11 16:17:00 UTC
(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.

Comment 3 Ryan Barry 2018-04-11 16:20:10 UTC
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()

Comment 4 Phillip Bailey 2018-04-11 16:46:21 UTC
(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.

Comment 5 Dominik Perpeet 2018-04-11 18:12:09 UTC
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

Comment 6 Denis Chaplygin 2018-04-12 09:02:36 UTC
Just verified with CLI - everything went fine, so it is a cockpit issue


@Ryan - that particular string definitely came from virsh, not from cockpit

Comment 7 Simone Tiraboschi 2018-04-20 09:27:08 UTC
*** Bug 1569372 has been marked as a duplicate of this bug. ***

Comment 8 Yihui Zhao 2018-04-26 03:34:11 UTC
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.

Comment 9 Ryan Barry 2018-04-30 14:40:08 UTC
*** Bug 1572721 has been marked as a duplicate of this bug. ***

Comment 10 Yihui Zhao 2018-05-02 09:16:17 UTC
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.

Comment 11 Martin Pitt 2018-05-09 14:16:50 UTC
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!

Comment 12 Sandro Bonazzola 2018-05-10 06:32:16 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.