Python Pip/Poetry Problems when using Gefyra with devcontainers

[buschNT]

Hello!

I have problems installing dependencies for my python app when using Gefyra with VSCode devcontainers. The setup can be found in https://github.com/Blueshoe/gefyra-devcontainer using getdeck to create the local cluster. The steps are documented in the README.

I have the feeling that the "gefyra run ..." command somehow "blocks" some connection between my devcontainer and the internet/pypi, and I do not understand why or if I have to provide additional configurations. Whenever I attach to the started devcontainer and try to run something like pip install poetry I get the following kind of errors:

Sometimes installations using pip seem to work, but when installing bigger projects with dependencies managed using poetry, I never get poetry install to finish successfully. It always gets stuck at seemingly random package installations. Sometimes it helps to generate the requirements.txt locally (poetry export -f requirements.txt --output requirements.txt --without-hashes), as pip installations are somehow more robust.

It feels more like a gefyra issue, because when I start the devcontainer directly from VSCode it seems to work just fine. However, I might be wrong and this could be a VSCode specific problem, but maybe you could take a look and see if you find/help me with the issue/configuration.

Thanks a lot!

[buschNT]

@SteinRobert Thanks for the debugging session. I shortly document our findings here.

It seems to be a pypi specific issue in combination with the gefyra cargo container. apt installations are working fine but pip installations using the default pypi connection are failing (already within the cargo container). Using a pypi mirror worked. This could be related to known pypi issues with proxy servers. Maybe the cargo needs some additional configuration to work with pypi out of the box.

[buschNT]

@Schille Thanks for the debugging session, too :D . Our findings:

The issue did not appear on @Schille 's Laptop. Here everything seemed to work just fine.

We traced the issue on my laptop to the TSL handshake of the Wireguard connection, which seemed to be getting stuck. Disabling the wireguard connection from within the cargo "resolved" the issue. Furthermore, when setting the MTU within the cargo to 1340 in the configuration file, curl https://pypi.python.org -vvv worked with active wireguard (values around 1400 did not work).

Start/Stop wireguard connection: wg-quick [up|down] /config/wg0.conf

[buschNT]

From within the devcontainer I get different errors when modifying the wireguard connection:

deactive wireguard

wiregurad with MTU of 1340 in cargo

[Schille]

I created an issue: #142

[schwobaseggl]

@buschNT I have had another problem that could be solved by setting the MTU within the cargo to 1340:
Certain database queries (from within django ORM) were timing out while others (simpler ones it seems, but the sample size is small) were super fast. After applying the lower MTU setting (thanks to @Schille), all queries were working normally.

[Schille]

I addressed this issue with PR: #144
It adds the argument gefyra up --wireguard-mtu <value> which you can use once you encounter such problems again.
Hopefully this will be available from version 0.9.1

[buschNT]

Thanks for the MTU fix! Poetry/pip seems to run without any problems within my bridged devcontainers after installing gefyra version 0.10.2 ❤️