Running tests requires sudo

[birdsarah]

I was running tests locally and surprised to find them asking for my sudo password!

Starting local_http_server
Starting HTTP Server in a separate thread
...serving at port 8000
Starting edge router (http port 4566)...
Please enter your sudo password (required to configure local network):
[sudo] password for birdsarah:

I'm pretty sure this is related to localstack services as per: localstack/localstack#2371

[birdsarah]

Workaround

$ export EDGE_PORT=9999

Before running tests.

[vringar]

Oof, just ran into this as well...
Should we just upgrade our localstack dependency or is this what breaks the camels back and gets us to use docker in testing?

[birdsarah]

They've fixed the issue, so yes, we should update. They were pretty quick to turn this around. Can we not ask for upstream fixes for our other issues?

[birdsarah]

(I do not want to use docker in testing, I had not realized that was the alternative).

(I have a general aversion to docker because I'm not that skilled with it. Which is not a good reason - I expect people, including myself, to know useful tools e.g. conda :). So please take my "bleugh docker" with a large grain of salt.

[vringar]

I just had to reboot my PC today because somehow running localstack[full] natively managed to screw up my entire setup to the point that nothing else worked to get the tests to pass again.
I also have weird intermittent issues where the s3 state persists throughout multiple test runs and similar
I understand your aversion but I hope that just like we came around to seeing conda as a useful tool with some explanation from your side I can convince you of docker

[birdsarah]

I can convince you of docker

I don't really need to be convinced of docker per se, I was just moaning.

How would docker replace localstack. Localstack gives us an AWS interface. What about S3 interface do we need to test?

[vringar]

Docker wouldn't replace localstack but instead of running localstack on the host and mangling all of our dependencies with theirs, we would run localstack as a docker container.
As such we could guarantee that we would wipe all artifacts after every test, and wouldn't have to pin some of our dependencies to older versions just because localstack needs them at that version.
If I figure out fixtures it would basically boil down to

1. Fixture spins up a docker container running localstack and sets the default session to point to that container
2. Test runs against a pristine instance of localstack
3. Container is torn down

This would also allow us to run tests in parallel as each test would have their dedicated localstack container and as such tests couldn't interfere with each other.