Ability to disable external download of devspacehelper
Is your feature request related to a problem?
When you start developing using devspace dev, devspace tries to download the latest devspacehelper binary via GitHub inside the container. However, most of our containers have no internet access, resulting in:
[2:sync] Warning: Couldn't download devspacehelper in container, error: stdout, stderr:
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (7) Failed to connect to github.com port 443 after 93 ms: Connection refused
: command terminated with exit code 7
[2:sync] Trying to inject devspacehelper from local machine
When this fails, devspace uploads the devspacehelper from your machine, using the already existing sync.
Which solution do you suggest?
Add the option in devspace.yaml to disable external download of the devspacehelper.
Which alternative solutions exist?
Not one that I know of.
Additional context
None.
/kind feature
@hvt thanks for opening this issue! I guess the problem here is more the error / warning instead of DevSpace trying to download the helper correct? We could only print that warning in --debug mode which would hide it by default.
Hey @FabianKramm, well, in a security restricted environment (mainly compliance related) making outside connections is prohibited, and also flagged / blocked by the firewall / mesh. So in our case it would be better to just avoid making such connections.
Just out of interest: what is the reason it tries to download the devspacehelper this way? Is it updated more regularly than devspace itself?
@hvt ah I see that makes sense, we could add an environment variable that would allow disabling this. Download is usually a lot faster than upload for most internet connections (especially personal internet connections) in remote environments, which is why download is preferred by default.
EDIT: I just saw we already have an environment variable for this which is called DEVSPACE_INJECT_LOCAL and skips downloading if set to "true"
And I would have to set this in the container where the devspacehelper is injected into?
Because I tried, but devspace still tries to download the helper:
...
19:26:07 [0:sync] Waiting for containers to start...
19:26:20 [0:sync] Starting sync...
19:26:20 [0:sync] Trying to download devspacehelper into pod hvt/crm-data-main-v1-7ff88b5c75-g98g9
19:26:20 [0:sync] Warning: Couldn't download devspacehelper in container, error: stdout, stderr:
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (7) Failed to connect to github.com port 443 after 2 ms: Connection refused
: command terminated with exit code 7
19:26:20 [0:sync] Trying to inject devspacehelper from local machine
...
$ devspace enter
# selecting the crm-data-main-v1
[info] Opening shell to pod:container crm-data-main-v1-7ff88b5c75-g98g9:crm-data-main-v1-server
/server $ env | grep DEVSPACE
DEVSPACE_INJECT_LOCAL=true
/server $ /tmp/devspacehelper version
v5.18.3
@hvt no you would set this locally either through the .env file or via:
DEVSPACE_INJECT_LOCAL=true devspace dev
@FabianKramm Thanks, that works:
[0:sync] Waiting for containers to start...
[0:ports] Port-Forwarding: Waiting for containers to start...
[0:sync] DevSpace is waiting, because Pod hvt/crm-data-main-v1-58d9c9ffcb-4dqjc has status: Init:0/2
[0:ports] DevSpace is waiting, because Pod hvt/crm-data-main-v1-58d9c9ffcb-4dqjc has status: Init:0/2
[0:sync] Starting sync...
[0:ports] Port forwarding started on 60635:8080 (hvt/crm-data-main-v1-58d9c9ffcb-4dqjc)
[0:sync] Trying to inject devspacehelper from local machine
[0:sync] Start syncing
[0:sync] Sync started on /home/hvt/dev/crm-data-main-v1/container/server <-> /server (Pod: hvt/crm-data-main-v1-58d9c9ffcb-4dqjc)
[0:sync] Waiting for initial sync to complete
[0:sync] Helper - Use inotify as watching method in container
[0:sync] Downstream - Initial sync completed
[0:sync] Upstream - Initial sync completed
Would it somehow be (or is it already?) possible to add a flag in devspace.yaml to enable this behavior? In our case, this now leads to supplying the devspace configuration using two separate files (.env & devspace.yaml), which feels unnecessary.
@hvt after some consideration and internal talks we decided to add an env section to the devspace.yaml where you can specify environment variables that should be set which should solve your problem
That sounds great, thank you.
(Just some advice for the docs later on, make sure to describe the distinguishment between the environment variables of the system devspace is running on, and the environment variables associated with the containers. That's what caught me here before :].)
@FabianKramm Does this environment variable still work? I am trying to use it now but it doesn't seem to work
@soggycactus I think the variable wound up being named DEVSPACE_INJECT_REMOTE instead of DEVSPACE_INJECT_LOCAL. Can you give that a try?