1559976 - [meta] Run telemetry-tests-client suite in Python 3

Status: RESOLVED FIXED

(Toolkit :: Telemetry, enhancement, P3)

Description

[Raphael Aurich [:raphael] UTC+01:00]

We're approaching the EOL for Python 2. This bug tracks the work required for running the telemetry-tests-client in Python 3.

Comment 1

[Chris Hartjes [:grumpy][:chartjes]]

Attachment: Bug 1559976 - Create version of Telemetry Client optout ping test that uses pytest intead of unittest; r?raphael

Comment 2

[Phabricator Automation]

Comment on attachment 9103340 [details]
Bug 1559976 - Create version of Telemetry Client optout ping test that uses pytest intead of unittest; r?raphael

Revision D50116 was moved to bug 1560185. Setting attachment 9103340 [details] to obsolete.

Comment 3

[[e-mail] (:bhearsum)]

This appears to need a new owner; I don't think Chris is with the company anymore.

Comment 4

[James Graham [:jgraham]]

So this is now blocking updating web-platform-tests from upstream (!) because upstream wptserve has dropped Python 2 support and marionette-harness is also using the vendored copy of wptserve as the server. I managed to fix most other things this broke but I'm getting lots of random timeouts in the telemetry client tests and my initial reaction is that it doesn't seem like something I'm going to be able to fix in the necessary timeframe (asap, but certainly in days not weeks).

I think the quick fix is going to be vendoring another copy of wptserve and using that for the marionette-harness based tests rather than the one from upstream.

However on the topic of this bug:

• This is now causing problems elsewhere as Python 2 support is being droppped
• Although the bugs this depends on aren't marked as fixed, in practice mozharness and marionette are mostly compatible with Python 3 due to fixes porting other suites.

Comment 5

[Andrew Halberstadt [:ahal]]

Attachment: gecko.log snippet

I'm not super keen on vendoring a separate copy of `wptserve` just to have Python 2 compatibility as telemetry-tests-client is the last mach command and is also blocking a bunch of mach / build system cleanup. Seems like we should try and figure the timeouts out.

After applying https://phabricator.services.mozilla.com/D108834 locally and running `python3 ./mach telemetry-tests-client`, I also see a bunch of timeouts. I've attached a snippet of my gecko.log. Lots of errors trying to submit to wptserve. James, does wptserve dump a log file somewhere?

Comment 6

[James Graham [:jgraham]]

No, but it does have logging so it should be possible to make a patch to enable dumping logs to a file.

Note that we did end up importing wptserve for python 2 in testing/web-platform/mozilla/tests/tools. However the mach virtualenvs should be configured to only use the py2 copy with Python 2 commands, so you should be getting the version in testing/web-platform/tests/tools automatically if you've opted in to Python 3.

Comment 7

[Andrew Halberstadt [:ahal]]

Attachment: Patch to view server logs

Nvm, I got the logs to display with this patch. Here is the error:

 0:04.93 pingserver ERROR Traceback (most recent call last):
  File "/home/ahal/dev/mozilla-central/testing/web-platform/tests/tools/wptserve/wptserve/handlers.py", line 362, in __call__
    rv = self.func(request, response)
  File "/home/ahal/dev/mozilla-central/toolkit/components/telemetry/tests/marionette/harness/telemetry_harness/ping_server.py", line 33, in pings_handler
    ping_data = json.loads(request_data)
  File "/home/ahal/.pyenv/versions/3.8.5/lib/python3.8/json/__init__.py", line 343, in loads
    s = s.decode(detect_encoding(s), 'surrogatepass')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8b in position 1: invalid start byte

Comment 8

[Andrew Halberstadt [:ahal]]

So in other words, looks like the bug is in a handler of the telemetry harness so no issues with wptserve at least!

Comment 9

[Andrew Halberstadt [:ahal]]

Turns out this was even sillier than a decoding error. The headers are still byte strings, so this if statement was False (as it's now b"gzip"). We were then trying to decode a gzipped json object.

I'll get a patch up in bug 1638991 (as I already have a stack going there).

Comment 10

[Raphael Aurich [:raphael] UTC+01:00]

Closing this meta bug as we have been running tt(c) on Python 3 since bug 1638991 landed.