Increase Authority reachability testing rate with low TestingAuthDirTimeToLearnReachability

In a TestingTorNetwork, when TestingAuthDirTimeToLearnReachability is much lower than its normal value of 30 minutes, bootstrap will happen much more reliably if we test reachability at a proportionally faster rate.

I'd like to multiply the number of routers tested every 10 seconds, by the proportion that TestingAuthDirTimeToLearnReachability is smaller than the expected 1280 second cycle length.

changed milestone to %Tor: unspecified

added SponsorS-deferred chutney component::core tor/tor milestone::Tor: unspecified parent::22463 points::small priority::medium severity::normal status::new testing tor-dirauth type::defect version::tor 0.2.7 labels

Fixed as part of #13718 (moved). Composing commits over the next week.

This fix means we don't have to do anything special for authority reachability testing to get #13976 (moved) to work as expected.

Trac:
Owner: N/A to teor
Status: new to assigned

The changes to tor in #13718 (moved) have fixed this:

Bugs: #13718 (moved), #13814 (moved), maybe #13787 (moved), #13839 (moved), #13924 (moved), #13823 (moved), #13929 (moved), #13963 (moved) Branch: bug13718-fast-bootstrap Note: There are 5 branches that start with bug13718, please choose the right one. Repository: ​​​​​​​​https://github.com/teor2345/tor.git

Trac:
Status: assigned to needs_review

I am now revising #13929 (moved) & #13928 (moved) separately from #13718 (moved), as this is particularly authority-related.

These changes are not required for the fast bootstrap case (10s) in #13718 (moved). They might be required for the comprehensive bootstrap case (30s) when we're not using TestingDirAuthVoteGuard * TestingDirAuthVoteExit *. (Although I really need to look into the guard case more.)

This needs some tests (check it covers all cases), and therefore probably needs some refactoring to be more testable.

The WIP branch for tor is:

Bugs: #13929 (moved), #13928 (moved) (in that order) Branch: faster-permuted-reachability Repository: ​​​​​​​https://github.com/teor2345/tor.git

Trac:
Status: needs_review to needs_revision

We will now track this as part of #14034 (moved) Make TestingDirAuthVoteGuard, TestingDirAuthVoteExit and AssumeReachable less essential in test networks.

Trac:
Parent: #13718 (moved) to #14034 (moved)

Let's have a look at this in 0.2.6, maybe.

Trac:
Milestone: N/A to Tor: 0.2.6.x-final

See #13928 (moved) for a new branch with these changes.

Trac:
Milestone: Tor: 0.2.6.x-final to N/A
Status: needs_revision to needs_review

Maybe 0.2.7

Trac:
Milestone: N/A to Tor: 0.2.7.x-final

Marking more tickets as triaged-in for 0.2.7

Trac:
Keywords: tor-auth testing chutney deleted, tor-auth, testing, 027-triaged-1-in, chutney added

Trac:
Keywords: N/A deleted, SponsorS added
Version: Tor: 0.2.6.1-alpha to Tor: 0.2.7

17:38 < nickm> hm. I see #13929 is part of #13928, and #13928 is in 
               needs_revision, so probably #13929 should be needs_revision too?

Trac:
Status: needs_review to needs_revision

I want to split this from #13928 (moved), as #13928 (moved) is a solution to a problem I don't think exists (authority reachability testing being predictable). And making it random could cause other hard-to-diagnose bugs.

But it would be useful to increase the rate at which we check reachability in test networks. I just don't think it's urgent - no-one seems to need it at the moment.

Trac:
Milestone: Tor: 0.2.7.x-final to Tor: 0.2.8.x-final
Keywords: 027-triaged-1-in deleted, N/A added

Trac:
Keywords: N/A deleted, 028-triaged added

Bulk-replace SponsorS keyword with SponsorS sponsor field in Tor component.

Trac:
Sponsor: N/A to SponsorS
Keywords: SponsorS deleted, N/A added

Trac:
Points: N/A to small

Trac:
Keywords: N/A deleted, pre028-patch added

This doesn't seem to be impacting test network bootstrap times at the moment, but that might be because we avoid using the reachability code and just assume everything is reachable.

Trac:
Severity: N/A to Normal

I'm going to bump this to 0.2.9. If anyone thinks we are having issues with the authority reachability code, or thinks we need to test it in chutney sooner, feel free to put it back in 0.2.8.

Trac:
Milestone: Tor: 0.2.8.x-final to Tor: 0.2.9.x-final
Keywords: 028-triaged, pre028-patch deleted, N/A added

Trac:
Reviewer: N/A to N/A
Sponsor: SponsorS to SponsorS-can

tickets market to be removed from milestone 029

Trac:
Milestone: Tor: 0.2.9.x-final to Tor: 0.2.???

Remove the SponsorS status from these items, which we already decided to defer from 0.2.9. add the SponsorS-deferred tag instead in case we ever want to remember which ones these were.

Trac:
Sponsor: SponsorS-can to N/A
Keywords: N/A deleted, SponsorS-deferred added

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

Trac:
Keywords: N/A deleted, tor-03-unspecified-201612 added
Milestone: Tor: 0.3.??? to Tor: unspecified

Remove an old triaging keyword.

Trac:
Keywords: tor-03-unspecified-201612 deleted, N/A added

Turns out that tor-auth is for directory authority so make it clearer with tor-dirauth

Trac:
Keywords: tor-auth deleted, tor-dirauth added

We should do this when we do #22463 (moved).

Trac:
Parent: #14034 (moved) to #22463 (moved)

Disowning tickets I don't intend to work on in the next 6 months.

Trac:
Status: needs_revision to assigned
Owner: teor to N/A

Mark all tickets that are assigned to nobody as "new".

Trac:
Status: assigned to new

mentioned in issue #13935 (moved)

mentioned in issue #13963 (moved)

mentioned in issue #13976 (moved)

mentioned in issue #14034 (moved)

mentioned in issue #22463 (moved)

moved to tpo/core/tor#13929 (closed)

mentioned in issue tpo/core/tor#14034 (closed)