[GitHub] [openwhisk-wskdebug] dilox commented on issue #67: wskdebug inside theia

[GitBox <gi...@apache.org>]

dilox commented on issue #67:
URL: https://github.com/apache/openwhisk-wskdebug/issues/67#issuecomment-646606657


   First of all, thanks for fast reply.
   
   >Where exactly do you see the error? What command do you run? What is “theia”? The port that fails - is that the debugger failing to connect to the debug port of the container started by openwisk? Where does the debugger run?
   
   theia (https://theia-ide.org/) is an editor, very similar to vscode, accessible from the browser. It runs inside docker in the same network (bridge) where openwhisk resides
   wskdebug runs trough a launch.json, similiar to this one:
   ```{
       // Use IntelliSense to learn about possible attributes.
       // Hover to view descriptions of existing attributes.
       // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
       "version": "0.2.0",
       "configurations": [
   
           {
               "type": "node",
               "request": "launch",
               "name": "wskdebug",
               "runtimeExecutable": "wskdebug",
               "args": [
                   "echo",
                   "${workspaceFolder}/echo.js",
                   "-l",
                   "-v"
               ],
               "localRoot": "${workspaceFolder}",
               "remoteRoot": "/code",
               "outputCapture": "std"
           }
   ```
   I tried also running wskdebug from inside the theia terminal with the same result.
   This is what I think it happens:
   - wskdebug creates a docker service.
   - wskdebug inspects the new service, finding the host and the port to which connect
   - after 10000 ms it fails to connect since service is binded on the docker network interfaces the volumes share
   
   > I think I have seen a similar problem before. Not with wskdebug but another use case of running openwhisk runtime containers locally. This was inside Jenkins, which ran in a container itself.
   
   Yes I think it is the same situation, docker in docker, the theia conteiners runs with:
   ``` -v /var/run/docker.sock:/var/run/docker.sock ```
   exactly like jenkins does
   
   >The solution there was to look at an environment variable that contains the host ip under which exposed ports of containers are “visible”.
   
   I didn't have this idea, thanks! Can you give me some extra details? Supposing I have the right ip (172.17.0.1), can you point me where to "patch" the code and say "use 172.17.0.1 instead of  127.0.0.1"? (I tried to tweak src/debugger.js, no luck)
   
   >AFAICS that is something that has to be passed in as even the docker daemon itself does not know the ip address of the host - at least the docker apis never include a hostname or ip when retrieving the exposed ports.
   Hence a solution could be another cli argument with that host ip, if it cannot be retrieved automatically.
   Note that the docker logic was just refactored in #61 and will be in the next 1.3.0 release.
   
   This sounds great! When do you think to release the refactored version?
   
   Thanks again, Pierluigi
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org