The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-10-18T16:55:55Zhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41356GitHub mirror for Onionbalance2023-10-18T16:55:55ZSilvio RhattoGitHub mirror for OnionbalanceThe [Onionbalance](https://onionbalance.readthedocs.io) codebase was recently [moved around](tpo/onion-services/onionbalance#10):
* From https://github.com/asn-d6/onionbalance to https://github.com/torproject/onionbalance.
* From https:...The [Onionbalance](https://onionbalance.readthedocs.io) codebase was recently [moved around](tpo/onion-services/onionbalance#10):
* From https://github.com/asn-d6/onionbalance to https://github.com/torproject/onionbalance.
* From https://gitlab.torproject.org/tpo/core/onionbalance to https://gitlab.torproject.org/tpo/onion-services/onionbalance.
Now I'd like to configure automatic pushes from Tor's GitLab to GitHub.
I'm aware of the [recommended procedure](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/gitlab#how-to-mirror-a-git-repository-from-gitlab-to-github) and have done it before, but I don't have admin access in the [GitHub repo](https://github.com/torproject/onionbalance) to proceed (my user on GitHub is [rhatto](https://github.com/rhatto/)).
Not sure if this is the right place to ask, but did so after finding a related issue (tpo/tpa/team#41246).Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42167Make the preference auto-focus more reliable2023-10-11T12:23:15ZhenryMake the preference auto-focus more reliableRight now testing with NVDA, the auto-focus implemented for https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41454 was not always reliable in getting the screen reader to read the Security Level panel.Right now testing with NVDA, the auto-focus implemented for https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41454 was not always reliable in getting the screen reader to read the Security Level panel.henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42166New identity dialog missing accessible name2023-10-11T12:22:45ZhenryNew identity dialog missing accessible nameThe new identity dialog is missing an accessible name, causing it to use the "chrome:" path as the dialog as a fallback.The new identity dialog is missing an accessible name, causing it to use the "chrome:" path as the dialog as a fallback.henryhenryhttps://gitlab.torproject.org/tpo/applications/rbm/-/issues/40062Copy input directories to containers recursively2023-10-13T05:17:30ZPier Angelo VendrameCopy input directories to containers recursivelyEarlier I've run a `firefox-android` build with `RBM_VERBOSE_LOG=1`.
I found that indeed we spend a [very long time copying files](/uploads/974c39037b48eb7f94954e4ee18194c7/android-copies.txt).
They are about 1600 files for slightly les...Earlier I've run a `firefox-android` build with `RBM_VERBOSE_LOG=1`.
I found that indeed we spend a [very long time copying files](/uploads/974c39037b48eb7f94954e4ee18194c7/android-copies.txt).
They are about 1600 files for slightly less than 500MB, so all this time is quite surprising.
My hypothesis is that it takes us this long time because we copy them one by one and we adjust their owner after each copy.
I wonder if this adds a lot of overhead (we need to setup the container and chroot to it to run `chown`).
My proposal is that we first copy directories (such as the various `gradle-dependencies-N`) recursively, and that we apply the owner only at the end of the copy.https://gitlab.torproject.org/tpo/network-health/tor-weather/-/issues/82Fix Tor Weather pipeline (pip install overrides poetry.lock pins)2023-11-23T10:02:49ZGeorg KoppenFix Tor Weather pipeline (pip install overrides poetry.lock pins)Building the Tor Weather wheel is working fine. However, we are failing in the `Verify` stage. While we do pin hashes in `poetry.lock` this gets bypassed by `python3 -m pip install dist/tor_weather-*.whl` which grabs the latest available...Building the Tor Weather wheel is working fine. However, we are failing in the `Verify` stage. While we do pin hashes in `poetry.lock` this gets bypassed by `python3 -m pip install dist/tor_weather-*.whl` which grabs the latest available versions it seems potentially resulting in a version mismatch and broken Tor Weather setups. For instance, right now we pin `flask` to version 2.3.3 but running `python3 -m pip install dist/tor_weather-*.whl` in our pipeline actually results in
```
Collecting flask (from tor-weather==1.1.1)
Obtaining dependency information for flask from https://files.pythonhosted.org/packages/36/42/015c23096649b908c809c69388a805a571a3bea44362fe87e33fc3afa01f/flask-3.0.0-py3-none-any.whl.metadata
Downloading flask-3.0.0-py3-none-any.whl.metadata (3.6 kB)
```Sarthik Guptasarthikg@icloud.comSarthik Guptasarthikg@icloud.comhttps://gitlab.torproject.org/tpo/core/arti/-/issues/1059futures::channel::oneshot severe bug affecting cleanup2023-10-11T16:02:52ZIan Jacksoniwj@torproject.orgfutures::channel::oneshot severe bug affecting cleanup`futures::channel::oneshot::Receiver` has a broken implementation of `FusedFuture` which makes it not work in `select!`. If the `Sender` is dropped, the `select!` functions as if the `Receiver` is never `Ready` (even though when you pol...`futures::channel::oneshot::Receiver` has a broken implementation of `FusedFuture` which makes it not work in `select!`. If the `Sender` is dropped, the `select!` functions as if the `Receiver` is never `Ready` (even though when you poll it it *is* `Ready` in this case). https://github.com/rust-lang/futures-rs/issues/2455
One big problem with this that on shutdown of part of Arti, it can cause tasks to hang rather than noticing everything has gone away and terminating.
Options:
1. Do something (what?) to try to spot when a `oneshot::Receiver` is used within `select!`, and call `.fuse()` on it (and store that somewhere) to get a properly working impl of `FusedFuture`. I don't think this is very viable unless we have a more concrete idea. (Hrm, can we make `<Receiver as FusedFuture>::is_terminated` a deprecated method and spot its uses by `select!`?)
2. Use Tokio's `oneshot`. Inspection of the implementation (thanks @trinity-1686a) reveals that it doesn't depend on the Tokio executor. Downside: every crate now ends up with a dep on Tokio. This is bad because it would make it easy to use other bits of tokio, despite our intent to be runtime-agnostic. It's also bad for our code size.
3. Use Tokio's `oneshot` but via a re-export it from `tor-async-utils.` That helps prevent the accidental use of Tokio but it doesn't help with code size.
4. Copy Tokio's `oneshot.rs` into `tor-async-utils`.
5. Use `postage::oneshot`. But it has a different (and rather less good) API.
6. Use `postage::oneshot` but wrap it in a newtype. I'm not sure the implementation of the good API in terms of the less good one will be much fun or very principled.
7. Write our own `oneshot`.
8. Use `FusedFuture<oneshot::Receiver<T>>` everywhere and enforce this by (i) making all the constructors like `oneshot::channel` deprecated and (ii) providing wrappers that wrap the `Receiver`. (This is an extra byte (probably word) of state for each `Receiver` and therefore will have a perf impact, so on super hot paths we might want something else. But we don't have many oneshots on super hot paths.)
CC @gabi-250 @nickm since this'll probably end up being a widespread thing.Ian Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/63[New] examples (a page with list of example projects from the repo)2023-12-20T13:40:34Zharleta[New] examples (a page with list of example projects from the repo)2023-10-14https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/issues/62[New] overview (Arti three ways)2023-12-20T13:41:51Zharleta[New] overview (Arti three ways)https://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/blob/c77837e821cbfe8a76cf2c24025cff16bf7605c7/docs/integrating-arti/integrating-arti.mdhttps://gitlab.torproject.org/tpo/core/arti-doc-project-2023/-/blob/c77837e821cbfe8a76cf2c24025cff16bf7605c7/docs/integrating-arti/integrating-arti.md2023-10-14https://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/40102tor-0.4.8 overestimates <OR> bridge users and underestimates PT bridge users2024-01-25T14:33:21ZDavid Fifielddcf@torproject.orgtor-0.4.8 overestimates <OR> bridge users and underestimates PT bridge usersLook at the graphs below.
As bridges have upgraded from tor-0.4.7 to tor-0.4.8,
two things have happened simultaneously:
1. The estimated number of bridge users using the \<OR\> protocol (no pluggable transport) has gone up.
2. The esti...Look at the graphs below.
As bridges have upgraded from tor-0.4.7 to tor-0.4.8,
two things have happened simultaneously:
1. The estimated number of bridge users using the \<OR\> protocol (no pluggable transport) has gone up.
2. The estimated number of bridge users using any pluggable transports has gone down.
It is no coincidence.
A bug was introduced in tor-0.4.8 that apparently causes the \<OR\> counter in
`bridge-ip-transports` to be incremented
every time the counter for any transport is incremented.
Bridges that formerly reported 0% \<OR\> and 100% transport <var>T</var>
are now reporting around 50% \<OR\> and 50% transport <var>T</var>.
Because per-transport directory requests are estimated
[according to the *ratios*](https://metrics.torproject.org/reproducible-metrics.html#bridge-users)
in `bridge-ip-transports`, this makes it appear as if half the bridge's users
are \<OR\> and half are transport <var>T</var>,
which makes the total \<OR\> count go up and the total pluggable transport count go down.
I believe the bug is in tor, not in metrics code,
but I'm opening an issue here because I don't know the cause
of the bug in tor yet, and because metrics may have to be aware
of the erroneous descriptors that have already been published.
@trinity-1686a [suspects](https://lists.torproject.org/pipermail/tor-dev/2023-October/014856.html)
commit https://gitlab.torproject.org/tpo/core/tor/-/commit/3e18507dc75afcf0c6560e966c9f18942406b0c8,
which would make the first affected release
[tor-0.4.8.4](https://forum.torproject.org/t/stable-release-0-4-8-4/8884)
on 2023-08-23.
[![Relay versions](/uploads/e1f1e65b138bcb6d12b026bf216f5015/versions-2023-07-11-2023-10-09.png){width=640px}](https://metrics.torproject.org/versions.html?start=2023-07-11&end=2023-10-09)
[![Bridge users by transport](/uploads/1a82ff4038d032771657f8dd26db0bc3/userstats-bridge-transport-2023-07-11-2023-10-09-__OR_-_OR_.png){width=640px}](https://metrics.torproject.org/userstats-bridge-transport.html?start=2023-07-11&end=2023-10-09&transport=%21%3COR%3E&transport=%3COR%3E)
I noticed this after tor upgrades on the Snowflake bridges.
Here are some excerpts from the thread on tor-dev.
https://lists.torproject.org/pipermail/tor-dev/2023-October/014855.html
> I upgraded one of the two Snowflake bridges from 0.4.7.13 to 0.4.8.6 on
> 2023-09-24. Since then, the number of \<OR\> IP addresses has been roughly
> equal to the number of snowflake IP addresses. The ORPort is still not
> exposed; these are not external vanilla bridge users. Did something
> change between these versions that might cause PT connections to be
> double-counted, once for the transport and once for \<OR\>?
>
> Here are excerpted bridge-extra-info descriptors from before and after
> the version upgrade. Note the `bridge-ip-transports` lines.
>
> ```
> @type bridge-extra-info 1.3
> extra-info crusty5 91DA221A149007D0FD9E5515F5786C3DD07E4BB0
> master-key-ed25519 1y9CAtinlbrhDuYBSOBNiCU9Ck1lcY7LErxnzhtxVks
> published 2023-09-19 10:46:08
> transport snowflake
> bridge-ip-versions v4=13528,v6=1384
> bridge-ip-transports <OR>=8,snowflake=14912
> ```
>
> ```
> @type bridge-extra-info 1.3
> extra-info crusty5 91DA221A149007D0FD9E5515F5786C3DD07E4BB0
> master-key-ed25519 1y9CAtinlbrhDuYBSOBNiCU9Ck1lcY7LErxnzhtxVks
> published 2023-09-29 17:33:20
> transport snowflake
> bridge-ip-versions v4=2880,v6=336
> bridge-ip-transports <OR>=1632,snowflake=1592
> ```
https://lists.torproject.org/pipermail/tor-dev/2023-October/014858.html
> The effect of this apparent bug is that the lower bound of per-country
> per-transport user count intervals goes to zero. See the first attached
> graph. The snowflake-01 bridge upgraded to 0.4.8 on 2023-10-03;
> snowflake-02 upgraded on 2023-09-24. Whereas formerly, the low–high
> intervals were so narrow as to be indistinguishable from a line, now
> they extend all the way down to the <var>x</var>-axis.
>
> ![Top 5 countries with the most Snowflake users by day](/uploads/f9f0ce55de779dc30ddb9cd1b099a80a/snowflake-top-countries-20231010.png){width=640px}
>
> The [formula for the lower bound](https://metrics.torproject.org/reproducible-metrics.html#bridge-users) is:
>
> > low = max(0, country_reqs + transport_reqs − total_reqs)
>
> On a bridge that hides its ORPort and runs just one transport, we have
> transport_reqs ≈ total_reqs, and so the above just becomes
>
> > low = max(0, country_reqs)
>
> But with the apparent metrics bug in 0.4.8.6, total_reqs is twice as
> large as it should be (i.e., 2 × transport_reqs ≈ total_reqs), which
> means the formula becomes
>
> > low = max(0, country_reqs − transport_reqs)
>
> which, since country_reqs < transport_reqs, always becomes zero.
>
> The upper bound of the interval is unaffected; its formula is
>
> > high = min(country_reqs, transport_reqs)
>
> The other side effect is that directory requests that ought to be
> attributed entirely to a pluggable transport are instead being ascribed
> 50/50 to that transport and the plain OR protocol. "We approximate
> [directory requests by transport] by multiplying the total number of
> requests with the fraction of unique IP addresses by transport." See, in
> the second attached graph, how estimated pluggable transport users have
> declined and OR protocol users have increased, in an almost inverse
> relationship, roughly in step with the 0.4.7→0.4.8 upgrade.
>
> https://metrics.torproject.org/userstats-bridge-transport.html?start=2023-07-11&end=2023-10-09&transport=%21%3COR%3E&transport=%3COR%3E
> https://metrics.torproject.org/versions.html?start=2023-07-11&end=2023-10-09HiroHiro2024-01-31https://gitlab.torproject.org/tpo/community/hackweek/-/issues/18Working on the content for the developer portal2023-11-30T16:16:39ZGabagaba@torproject.orgWorking on the content for the developer portal# About the project
* Contact: @gaba
* Chat: #tor-dev on `irc.oftc.net`
* Video room: https://tor.meet.coop/gab-tph-u9q-eo0
* Meet Monday, Tuesday, Wednesday, Thursday from 12UTC to 20UTC
# Participants
- @gaba
- you?
# Summary
...# About the project
* Contact: @gaba
* Chat: #tor-dev on `irc.oftc.net`
* Video room: https://tor.meet.coop/gab-tph-u9q-eo0
* Meet Monday, Tuesday, Wednesday, Thursday from 12UTC to 20UTC
# Participants
- @gaba
- you?
# Summary
The [developer portal](https://gitlab.torproject.org/tpo/web/dev/) has been on the back waiting for some time to get completed. At the beginning of this year Ura.Design worked on a [site/design](https://gitlab.torproject.org/tpo/web/dev/-/issues/6) for it. This is a project to get the content into the site and reviewing the information architecture.
## Project A : Get content into the portal
The content that we are planning to have in this portal is all over the place in repositories and wikis. With this project I will move the content to the dev portal, review the information architecture and organize the work that needs to happen next.
# Skills
- Gitlab
- Writing documentation
- MarkdownHackweek 2023Gabagaba@torproject.orgGabagaba@torproject.org2023-11-09https://gitlab.torproject.org/tpo/team/-/issues/221Sponsor 9 Report2023-11-30T18:35:57ZGabagaba@torproject.orgSponsor 9 ReportWrite report for sponsor 9 for previous phase (July 2022 to June 2023).Write report for sponsor 9 for previous phase (July 2022 to June 2023).Gabagaba@torproject.orgGabagaba@torproject.org2023-11-16https://gitlab.torproject.org/tpo/network-health/onbasca/-/issues/169Check `Token` header instead of `Cookie` header from rdsys2023-11-06T08:36:47ZjugaCheck `Token` header instead of `Cookie` header from rdsysIn #162 we decided that onbrisca authorizes the requests via a token in `Cookie` header, however tpo/anti-censorship/rdsys#174 doesn't set it with the `Cookie` header but the `Token` and `Authorization` headers. Therefore onbrisca has al...In #162 we decided that onbrisca authorizes the requests via a token in `Cookie` header, however tpo/anti-censorship/rdsys#174 doesn't set it with the `Cookie` header but the `Token` and `Authorization` headers. Therefore onbrisca has already been changed in production to look at these header instead to authorize the request.jugajugahttps://gitlab.torproject.org/tpo/team/-/issues/219Budget for Translations into Turkmen2024-01-16T13:08:32ZGabagaba@torproject.orgBudget for Translations into TurkmenWe need to write the budget and scope to request Localization Lab for the translation for turkmen.
cc @emmapeelWe need to write the budget and scope to request Localization Lab for the translation for turkmen.
cc @emmapeelGabagaba@torproject.orgGabagaba@torproject.orghttps://gitlab.torproject.org/tpo/core/torspec/-/issues/223Convert specifications to mdbook2023-10-26T14:20:06ZNick MathewsonConvert specifications to mdbookPer [proposal 345](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/345-specs-in-mdbook.md), I want to convert our specifications to markdown and render them in mdbook.
The end result of the migration will be that:...Per [proposal 345](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/345-specs-in-mdbook.md), I want to convert our specifications to markdown and render them in mdbook.
The end result of the migration will be that:
* The torspec repository looks more [like this](https://gitlab.torproject.org/nickm/torspec/-/tree/spec_conversion?ref_type=heads).
* There is rendered torspec website looks more [like this](https://people.torproject.org/~nickm/volatile/mdbook-specs/index.html).
It looks like [spec.tpo](https://spec.torproject.org) is available as a target for this rendering; @weasel (the current spec.tpo maintainer) has approved on IRC. There is a [TPA ticket](https://gitlab.torproject.org/tpo/tpa/team/-/issues/41348) open for the admin side of the issue, and I've gotten some helpful advice there too.
On this ticket I'll be tracking the actual details of doing the migration. I won't do anything final without talking to more people, though.
Next steps here are:
* [x] Decide on the new layout we want for torspec.git.
* [x] Decide on the URL layout we want for the new spec.tpo website.
- Should we have a landing page, or should the mdbook content **be** the landing page?
- Should we leave a spot for RFCs?
* [ ] Work on [the migration scripts](https://gitlab.torproject.org/nickm/torspec-converter) and their configuration (including where to break the sections), until they produces output we like, and it gives us the layout we want.
* [ ] Develop the CI process as needed to keep the site up to date.
- Probably, publish to gitlab pages at first.
* [ ] Figure out whose approval we need for this, and see what they think.
* [ ] Write documentation as needed to explain how to edit the spec.
* [ ] Decide how to maintain redirects and permalinks.
After we've done this stuff I think we are ready to start the migration.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42154Empty the clipboard on browser shutdown only if content comes from private br...2023-11-07T16:50:23Zcypherpunks1Empty the clipboard on browser shutdown only if content comes from private browsing windowsThe user may not expect or need this feature (#42019) and maybe it should additionally be disabled for non-private browsing mode.
One issue is that the clipboard is emptied even if its contents did not originate from a browser.The user may not expect or need this feature (#42019) and maybe it should additionally be disabled for non-private browsing mode.
One issue is that the clipboard is emptied even if its contents did not originate from a browser.ma1ma1https://gitlab.torproject.org/tpo/network-health/team/-/issues/332New round of contacting operators for DNS issues and badexiting problematic r...2024-02-26T13:15:12ZGeorg KoppenNew round of contacting operators for DNS issues and badexiting problematic relays (10/05/2023)We got three relays in this week's report:
```
Relay 425E753462E703B4A05632175D884B36B481D368 failed DNS check 1/1 times
Relay DEA0BB5DEF392C40DD586E2906F9BC4BB3AC7773 failed DNS check 5/5 times
Relay E0C90700FE1F81044A086591DCB14F02797A...We got three relays in this week's report:
```
Relay 425E753462E703B4A05632175D884B36B481D368 failed DNS check 1/1 times
Relay DEA0BB5DEF392C40DD586E2906F9BC4BB3AC7773 failed DNS check 5/5 times
Relay E0C90700FE1F81044A086591DCB14F02797AC14B failed DNS check 5/5 times
```
The first one is offline right now but I'll reach out to the other two. I believe the second one has more trouble than mere DNS issues, though, as I was seeing weird occurences of `PR_END_OF_FILE_ERROR`s while loading websites in Tor Browser. Reaching websites per IP address does not work either.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41348Help needed with torspec migration (see proposal 345) hosting.2024-01-11T21:34:29ZNick MathewsonHelp needed with torspec migration (see proposal 345) hosting.Hi! As part of [proposal 345](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/345-specs-in-mdbook.md), I want to migrate the rendered format of torspec.git to the web. We'll have a nice easy gitlab CI hook that get...Hi! As part of [proposal 345](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/345-specs-in-mdbook.md), I want to migrate the rendered format of torspec.git to the web. We'll have a nice easy gitlab CI hook that gets run whenever the specs change, but after that point the whole process becomes a bit murky in my head.
To be concrete, here is what I'd like (if it's not too hard):
1. I'd like to know the right way to cause the CI hook to result in a pile of rendered HTML getting put on spec.tpo. This can replace the existing content of spec.tpo, which won't need to be on puppet any longer; I'll be sure to keep the links working.
2. If possible, I'd like a temporary subdomain (specs2.torproject.org? specs-demo.torproject.org?) for the script to target while to target while this is under development. This subdomain doesn't need to get CDN support, and it can get deleted completely after the migration is done and the CI hooks target the regular spec.tpo.
As an alternative to 2, we could just temporarily blow away spec.tpo, but that would put more time pressure on me to get it fixed fast, which might not be so great.anarcatanarcathttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41347Move tor-pristine-upstream.git to GitLab2023-11-29T22:24:59ZJérôme Charaouilavamind@torproject.orgMove tor-pristine-upstream.git to GitLabDuring a work session with @weasel today about releasing new tor versions to our Debian repository we agreed we should move over `tor-pristine-upstream.git` to GitLab, as it currently lives only on git-rw.tpo.During a work session with @weasel today about releasing new tor versions to our Debian repository we agreed we should move over `tor-pristine-upstream.git` to GitLab, as it currently lives only on git-rw.tpo.legacy Git infrastructure retirement (TPA-RFC-36)Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/core/onionmasq/-/issues/71Update docker images, need rust => 1.70.02023-10-05T14:57:22ZkwadronautUpdate docker images, need rust => 1.70.0The cli improvements in !149 require a newer docker image. Current one is using Ubuntu 20.04 with Rust 1.67.0.
I'm not quite sure about the labels or milestones, if missing or wrong: sorry.The cli improvements in !149 require a newer docker image. Current one is using Ubuntu 20.04 with Rust 1.67.0.
I'm not quite sure about the labels or milestones, if missing or wrong: sorry.kwadronautkwadronauthttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41346Migrate pauli to gnt-dal2023-10-11T12:35:03ZJérôme Charaouilavamind@torproject.orgMigrate pauli to gnt-dalWhile working on tpo/tpa/team#41341 we figured out that the latency between gnt-dal and gnt-fsn is likely the cause of additional delays when running a Puppet agent run, when `pauli` is configured to use the `puppetdb-01` PuppetDB backen...While working on tpo/tpa/team#41341 we figured out that the latency between gnt-dal and gnt-fsn is likely the cause of additional delays when running a Puppet agent run, when `pauli` is configured to use the `puppetdb-01` PuppetDB backend.
We decide to attempt to migrate `pauli` from gnt-fsn to gnt-dal in the hope that this will remove the extraneous delays.Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.org2023-10-12