On Mon, May 11, 2020 at 8:52 PM teor teor@riseup.net wrote:
Hi Nick,
On 12 May 2020, at 06:48, Nick Mathewson nickm@torproject.org wrote:
## Migration steps
First, we implement all of the above, but set it to be disabled by default. We use torrc fields to selectively enable them for testing purposes, to make sure they work.
Can you expand on the testing plan here?
One of the risks with multi-year migration projects is that unrelated changes break the migration, and we don't notice.
For example, you might need to create a chutney network for each stage, and run them on every pull request and merge. In our current CI, that's 30-60 seconds of extra time per network, or 2-4 extra minutes of CI time.
If you need to test different combinations of features for each stage, let's try to do that in the same networks. Otherwise, the testing matrix expands out very quickly.
I agree here think that the right approach here is to test for the various ways that we expect the network to exist at a time. The trickiest stage of the migration will be the one where some services support ntor keys and some don't, some clients do and some don't. If we add a chutney network for that case specifically and make sure that all clients can reach all services, we should be fine here.