Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AMS migration: assist and provide feedback (4/n) #461

Closed
6 tasks done
bassosimone opened this issue Oct 23, 2020 · 5 comments
Closed
6 tasks done

AMS migration: assist and provide feedback (4/n) #461

bassosimone opened this issue Oct 23, 2020 · 5 comments
Assignees

Comments

@bassosimone
Copy link
Contributor

bassosimone commented Oct 23, 2020

Following up from #456. These are the remaining task:

List above poised to shrink/grow as the time progresses. See also #437.

@bassosimone
Copy link
Contributor Author

Regarding the old collector onion addresses:

  • ams-ps.ooni.nu is bouncer.ooni.io
  • mia-ps2.ooni.nu exposes hcn5nqahdkds6cjv.onion (which was previously announced by the bouncer as a valid collector)
  • ams-p2.ooni.nu exposes jehhrikjjqrlpufu.onion (which was previously announced by the bouncer as a valid collector)

This should inform our future actions.

bassosimone added a commit to measurement-kit/measurement-kit that referenced this issue Nov 6, 2020
bassosimone added a commit to ooni/probe-android that referenced this issue Nov 10, 2020
bassosimone added a commit to ooni/probe-ios that referenced this issue Nov 10, 2020
bassosimone added a commit to ooni/probe-engine that referenced this issue Nov 10, 2020
bassosimone added a commit to ooni/probe-engine that referenced this issue Nov 10, 2020
@bassosimone
Copy link
Contributor Author

bassosimone commented Nov 10, 2020

I've chosen not to merge ooni/probe-android#383 and ooni/probe-ios#397 as explained above. The last piece of work here concerns whether to change ooni/e2etesting. Since we're not using explicit names in ooni/e2etesting for quite some time now, and since we wanted to have periodic testing of our production infra, I would say it's actually fine for us to continue doing so. As such, this issue can now be declared complete. 🥳 🥳 🥳 🥳

@bassosimone
Copy link
Contributor Author

As discussed with @FedericoCeratto, we want to test the testing infra in github.com/ooni/e2etesting.

@bassosimone
Copy link
Contributor Author

bassosimone commented Nov 13, 2020

This is the current situation in terms of clients listing only clients with 1% or more measurements:

software_name software_version platform count percentage
ooniprobe 2.1.0 linux 574591 47.933993
ooniprobe 2.3.0 macos 211476 17.641921
ooniprobe-android 2.7.0 android 57621 4.806905
ooniprobe-desktop 3.0.4 windows 52483 4.378279
ooniprobe-cli 3.0.9 linux 50971 4.252144
ooniprobe 2.2.0 macos 36698 3.061450
ooniprobe 2.2.0 linux 34772 2.900778
ooniprobe 2.3.0 lepidopter 29610 2.470149
ooniprobe-cli 3.0.7-beta.1 linux 26895 2.243656
ooniprobe 2.1.0 macos 20913 1.744621
ooniprobe-desktop 3.0.4 macos 17326 1.445384
ooniprobe-cli 3.0.0 linux 16770 1.399000
ooniprobe 2.2.0 lepidopter 13401 1.117949

Computed using this query:

SELECT 
      software_name
    , software_version
    , platform
    , count(*) 
FROM 
    fastpath
WHERE
        test_start_time > NOW() - interval '7 day'
    AND test_name <> 'ndt'
GROUP BY
      software_name
    , software_version
    , platform
;

We exclude ndt because we have many tests running it using an old version of measurement_kit. A good question is whether we should break this legacy use case (I think we really should not).

bassosimone added a commit to ooni/e2etesting that referenced this issue Nov 13, 2020
MK is increasingly less important to us. But we know that we have
people running versions of MK compiled by themselves.

These persons mainly run NDT tests.

To have some confidence we're not breaking their workflows, let us
periodically run a MK probe from macOS against the testing infra.

This end-to-end test is not very precise, because we are not running
the same version they are running and maybe it's not even the same
OS and we likely have different dependencies. Yet, it seems a reasonable
best effort at ensuring we ain't breaking things too badly.

See ooni/backend#461 (comment)
bassosimone added a commit to ooni/e2etesting that referenced this issue Nov 13, 2020
Limit the runs to versions of the legacy probes that have been
running non-ndt-measurements in the last seven days.

See ooni/backend#461 (comment).

Make sure we target both production and testing.

As far as testing is concerned, just point to the HTTPS version to
ensure that there are no API breakages for now.
bassosimone added a commit to ooni/e2etesting that referenced this issue Nov 13, 2020
* fix: run MK on macOS w/ testing infra only

MK is increasingly less important to us. But we know that we have
people running versions of MK compiled by themselves.

These persons mainly run NDT tests.

To have some confidence we're not breaking their workflows, let us
periodically run a MK probe from macOS against the testing infra.

This end-to-end test is not very precise, because we are not running
the same version they are running and maybe it's not even the same
OS and we likely have different dependencies. Yet, it seems a reasonable
best effort at ensuring we ain't breaking things too badly.

See ooni/backend#461 (comment)

* fix: tweak legacy probe versions and targets

Limit the runs to versions of the legacy probes that have been
running non-ndt-measurements in the last seven days.

See ooni/backend#461 (comment).

Make sure we target both production and testing.

As far as testing is concerned, just point to the HTTPS version to
ensure that there are no API breakages for now.

* fix: tweak probe-cli related checks

1. ensure we build the most relevant versions (unfortunately we still
have some people who's running probe-cli 3.0.0 with MK)

2. ensure we test both prod and testing
@bassosimone
Copy link
Contributor Author

With the merging of ooni/e2etesting#26, we're really done here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant