Timeout on HTTP request

[Achllle]

Possibly related: #224

When I run npm start, I don't receive errors until after 60 seconds I get the following timeout. I'm not familiar with front-end so I'm not sure how to debug.

I'm running inside a docker container and manually did export DOCKER_HOST=127.0.0.1:50002 as it wouldn't be able to connect to the host otherwise. When navigating to localhost:3000, it simply shows a white screen.

Trace

[start:react] Compiled successfully!load Completed in 12ms
[start:react] 
[start:react] You can now view romi-dashboard in the browser.
[start:react] 
[start:react]   Local:            http://localhost:3000
[start:react]   On Your Network:  http://192.168.1.22:3000
[start:react] 
[start:react] Note that the development build is not optimized.
[start:react] To create a production build, use npm run build.
[start:react] 
[..................] \ : timing npm:load Completed in 12ms
[start:auth] An HTTP request took too long to complete. Retry with --verbose to obtain debug information.
[start:auth] If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60).
[start:auth] npm timing command:run-script Completed in 60413ms
[start:auth] npm verb stack Error: command failed
[start:auth] npm verb stack     at ChildProcess.<anonymous> (/root/.nvm/versions/node/v15.8.0/lib/node_modules/npm/node_modules/@npmcli/promise-spawn/index.js:64:27)
[start:auth] npm verb stack     at ChildProcess.emit (node:events:378:20)
[start:auth] npm verb stack     at maybeClose (node:internal/child_process:1067:16)
[start:auth] npm verb stack     at Process.ChildProcess._handle.onexit (node:internal/child_process:301:5)
[start:auth] npm verb pkgid romi-dashboard@0.0.1-alpha.0
[start:auth] npm verb cwd /rmf-web/packages/dashboard
[start:auth] npm verb Linux 5.8.0-41-generic
[start:auth] npm verb argv "/root/.nvm/versions/node/v15.8.0/bin/node" "/root/.nvm/versions/node/v15.8.0/bin/npm" "run" "start:auth"
[start:auth] npm verb node v15.8.0
[start:auth] npm verb npm  v7.5.1
[start:auth] npm ERR! code 1
[start:auth] npm ERR! path /rmf-web/packages/dashboard
[start:auth] npm ERR! command failed
[start:auth] npm ERR! command sh -c . e2e/env.sh && scripts/dockert docker-compose -f docker/docker-compose.yml up auth
npm verb exit 1
[start:auth] npm timing npm Completed in 60519msed in 12ms
[start:auth] 
[start:auth] npm ERR! A complete log of this run can be found in:
[start:auth] npm ERR!     /root/.npm/_logs/2021-02-10T00_13_11_803Z-debug.log

Said log file:

0 verbose cli [
0 verbose cli   '/root/.nvm/versions/node/v15.8.0/bin/node',
0 verbose cli   '/root/.nvm/versions/node/v15.8.0/bin/npm',
0 verbose cli   'run',
0 verbose cli   'start:auth'
0 verbose cli ]
1 info using npm@7.5.1
2 info using node@v15.8.0
3 timing config:load:defaults Completed in 1ms
4 timing config:load:file:/root/.nvm/versions/node/v15.8.0/lib/node_modules/npm/npmrc Completed in 1ms
5 timing config:load:builtin Completed in 1ms
6 timing config:load:cli Completed in 1ms
7 timing config:load:env Completed in 0ms
8 timing config:load:file:/rmf-web/packages/dashboard/.npmrc Completed in 0ms
9 timing config:load:project Completed in 0ms
10 timing config:load:file:/root/.npmrc Completed in 1ms
11 timing config:load:user Completed in 1ms
12 timing config:load:file:/root/.nvm/versions/node/v15.8.0/etc/npmrc Completed in 0ms
13 timing config:load:global Completed in 0ms
14 timing config:load:cafile Completed in 0ms
15 timing config:load:validate Completed in 1ms
16 timing config:load:setUserAgent Completed in 0ms
17 timing config:load:setEnvs Completed in 0ms
18 timing config:load Completed in 5ms
19 verbose npm-session 5dac68e641a2d11c
20 timing npm:load Completed in 9ms
21 timing command:run-script Completed in 60413ms
22 verbose stack Error: command failed
22 verbose stack     at ChildProcess.<anonymous> (/root/.nvm/versions/node/v15.8.0/lib/node_modules/npm/node_modules/@npmcli/promise-spawn/index.js:64:27)
22 verbose stack     at ChildProcess.emit (node:events:378:20)
22 verbose stack     at maybeClose (node:internal/child_process:1067:16)
22 verbose stack     at Process.ChildProcess._handle.onexit (node:internal/child_process:301:5)
23 verbose pkgid romi-dashboard@0.0.1-alpha.0
24 verbose cwd /rmf-web/packages/dashboard
25 verbose Linux 5.8.0-41-generic
26 verbose argv "/root/.nvm/versions/node/v15.8.0/bin/node" "/root/.nvm/versions/node/v15.8.0/bin/npm" "run" "start:auth"
27 verbose node v15.8.0
28 verbose npm  v7.5.1
29 error code 1
30 error path /rmf-web/packages/dashboard
31 error command failed
32 error command sh -c . e2e/env.sh && scripts/dockert docker-compose -f docker/docker-compose.yml up auth
33 verbose exit 1

I tried setting COMPOSE_HTTP_TIMEOUT to 180 seconds but got the same error.

Possibly separate issue

I had to pip install flask flask-socketio flask-cors for it to compile.

[koonpeng]

A white screen is usually because it can't connect to the auth server. The auth we use is keycloak, which is launched in a docker container. If you are using running the whole thing in docker, you need to properly set it up for docker-in-docker. I see you are trying to connect to the daemon at 127.0.0.1:50002, are you sure that it is where your daemon is? iirc that port is also used by ros2-bridge so you will probably get port conflicts.

Also, I see that you are using node v15, only node >= 12.20, <13 is supported due to rclnodejs.

[Achllle]

Appreciate your help with this. You're right that's not where the daemon was, in fact it wasn't running. Went back to docker-in-docker instructions and set it up properly (hopefully). Also reverted back to node v12 (I'm new to node). Now it runs without those initial errors.

Still a white screen:

[start:rmf] [schedule_visualizer-1] [INFO] [1612981794.772621105] [viz]: Connected with a client
[start:auth] Digest: sha256:5615984873a36b23852d867703ccb4b07bd907a2cdf991d1d7352872340739eb
[start:auth] Status: Downloaded newer image for quay.io/keycloak/keycloak:11.0.0
[start:auth]  ---> 8cb8b79c66a2
[start:auth] Step 2/2 : ADD --chown=jboss:jboss keycloak.mv.db /opt/jboss/keycloak/standalone/data/
[start:auth] Service 'auth' failed to build: error creating aufs mount to /var/lib/docker/aufs/mnt/24074c946b7b70590f18a3b4c12855005631e61c63c8ca92f720eb56582baf6d: mount target=/var/lib/docker/aufs/mnt/24074c946b7b70590f18a3b4c12855005631e61c63c8ca92f720eb56582baf6d data=br:/var/lib/docker/aufs/diff/24074c946b7b70590f18a3b4c12855005631e61c63c8ca92f720eb56582baf6d=rw:/var/lib/docker/aufs/diff/b7eecb5b086fbe8f507c542f287cf22abc2dfbad8cd8b8a6fcf7d98405873037=ro+wh:/var/lib/docker/aufs/diff/d0992a2ed6c46de1f8fe929b7d16a16aac6a05a9c7b97d31ab8332cf8b714f7b=ro+wh:/var/lib/docker/aufs/diff/bae4eabfbb25b2a0464249756fd56521475ae40e5030a490d3bc5db39180618d=ro+wh:/var/lib/docker/aufs/diff/a0837a71e706fdf73fbcabe26f1f37bf24557e5ba5c16a3b63f71445c11036b4=ro+wh:/var/lib/docker/aufs/diff/ddf8ec2fb97c0220abca3d8d8fa6582054e0b9056837f88feb286be32a9752bc=ro+wh,dio,xino=/dev/shm/aufs.xino: invalid argument
[start:auth] npm ERR! code ELIFECYCLE
[start:auth] npm ERR! errno 1
[start:auth] npm ERR! romi-dashboard@0.0.1-alpha.0 start:auth: `. e2e/env.sh && scripts/dockert docker-compose -f docker/docker-compose.yml up auth`
[start:auth] npm ERR! Exit status 1
[start:auth] npm ERR! 
[start:auth] npm ERR! Failed at the romi-dashboard@0.0.1-alpha.0 start:auth script.
[start:auth] npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
[start:auth] 
[start:auth] npm ERR! A complete log of this run can be found in:
[start:auth] npm ERR!     /root/.npm/_logs/2021-02-10T18_30_56_699Z-debug.log

said log file:

2 info using npm@6.14.10
3 info using node@v12.20.1
4 verbose run-script [ 'prestart:auth', 'start:auth', 'poststart:auth' ]
5 info lifecycle romi-dashboard@0.0.1-alpha.0~prestart:auth: romi-dashboard@0.0.1-alpha.0
6 info lifecycle romi-dashboard@0.0.1-alpha.0~start:auth: romi-dashboard@0.0.1-alpha.0
7 verbose lifecycle romi-dashboard@0.0.1-alpha.0~start:auth: unsafe-perm in lifecycle true
8 verbose lifecycle romi-dashboard@0.0.1-alpha.0~start:auth: PATH: /root/.nvm/versions/node/v12.20.1/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/rmf-web/packages/dashboard/node_modules/.bin:/root/.nvm/versions/node/v12.20.1/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/rmf-web/packages/dashboard/node_modules/.bin:/root/.nvm/versions/node/v12.20.1/bin:/rmf_demos_ws/install/traffic_editor/bin:/opt/ros/foxy/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
9 verbose lifecycle romi-dashboard@0.0.1-alpha.0~start:auth: CWD: /rmf-web/packages/dashboard
10 silly lifecycle romi-dashboard@0.0.1-alpha.0~start:auth: Args: [
10 silly lifecycle   '-c',
10 silly lifecycle   '. e2e/env.sh && scripts/dockert docker-compose -f docker/docker-compose.yml up auth'
10 silly lifecycle ]
11 silly lifecycle romi-dashboard@0.0.1-alpha.0~start:auth: Returned: code: 1  signal: null
12 info lifecycle romi-dashboard@0.0.1-alpha.0~start:auth: Failed to exec start:auth script
13 verbose stack Error: romi-dashboard@0.0.1-alpha.0 start:auth: `. e2e/env.sh && scripts/dockert docker-compose -f docker/docker-compose.yml up auth`
13 verbose stack Exit status 1
13 verbose stack     at EventEmitter.<anonymous> (/root/.nvm/versions/node/v12.20.1/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:332:16)
13 verbose stack     at EventEmitter.emit (events.js:314:20)
13 verbose stack     at ChildProcess.<anonymous> (/root/.nvm/versions/node/v12.20.1/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
13 verbose stack     at ChildProcess.emit (events.js:314:20)
13 verbose stack     at maybeClose (internal/child_process.js:1022:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:287:5)
14 verbose pkgid romi-dashboard@0.0.1-alpha.0
15 verbose cwd /rmf-web/packages/dashboard
16 verbose Linux 5.8.0-41-generic
17 verbose argv "/root/.nvm/versions/node/v12.20.1/bin/node" "/root/.nvm/versions/node/v12.20.1/bin/npm" "run" "start:auth"
18 verbose node v12.20.1
19 verbose npm  v6.14.10
20 error code ELIFECYCLE
21 error errno 1
22 error romi-dashboard@0.0.1-alpha.0 start:auth: `. e2e/env.sh && scripts/dockert docker-compose -f docker/docker-compose.yml up auth`
22 error Exit status 1
23 error Failed at the romi-dashboard@0.0.1-alpha.0 start:auth script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]

Any idea?

[koonpeng]

Service 'auth' failed to build: error creating aufs mount

Thats a problem with your docker installation. Make sure your dind is working correctly.

[Achllle]

Are there other ways that don't involve installing natively? Is it possible to remove the use of docker with this repo? I imagine I won't be the only one who wants to run this in a containerized environment.

[koonpeng]

You can try using a VM.

To be clear, we do run this in containerized environment for testing/staging/demo purposes. However, there is a difference between "running in containers" and "developing in containers", the instructions and scripts are meant for development purposes and there is no plans to provide a "development container". It is assumed that users that would like to develop in docker will need to know how to set up their own environment.

[codebot]

@Achllle do you have a way to make this work? If you are used to developing in containers and have ways to work around this, we would be happy to consider adding additional instructions for a setup like yours.

[Achllle]

It is assumed that users that would like to develop in docker will need to know how to set up their own environment.

I'm not sure if you realize if these words can be interpreted as quite rude. There's a learning curve to any new repo and telling people to 'go figure it out' means that they'll most likely avoid it altogether. I'm assuming a young project like this would welcome contributors, especially from robotics engineers working on large-scale fleet control, but I might be wrong.

There are a lot of dependencies and so I strongly prefer to test out and develop on this software out in a container to keep my native OS clean. I could go down the VM route but would rather containerize. I'd definitely appreciate some help with this or further instructions. I'd be more than happy to contribute back what I've learned in the form of documentation. Much appreciated!

[codebot]

@Achllle rudeness was certainly not @koonpeng 's intent; as you know, tone is hard to convey through brief text-only comments. We definitely need, want, and appreciate any and all contributions. You are certainly correct that RMF + ROS 2 + Gazebo/Ignition + React + many-other-things is a fantastic set of dependencies, and it would be great to find a nicer way to allow contributors to jump in without having to install many hundred packages on their machine.

At the moment our web team does not develop inside containers on a daily basis, so we just don't have the first-hand experience to write a detailed guide. I tried and failed to set up Keycloak myself last month without using the Keycloak containerized setup. I'm certainly not an expert in containers, but I think this is because Keycloak is Java-based and getting all the Java versioning right in the "parent" container and/or host is tricky. I'd be very interested to learn how to do it. I think everyone is different in this regard, but I prefer to develop "natively" (without containers) and I'd love to get rid of the Keycloak container and Docker dependency if it's possible, but I just couldn't figure out how to do so. But I only spent maybe 1-2 hours on it, probably with more effort it would be possible to match the required Java versions with either a parent container that also has RMF, and/or with the actual host machine distro. Finding a way to run Keycloak other than in its own container seems like it could help people wanting to either not use Docker at all, as well as people who want to run and develop RMF+Keycloak in the same container, if I understand correctly.

Any other suggestions for container-friendly development would be most appreciated; I think that you have a lot more experience with this than we do. Is there a different auth/JWT system that you prefer besides Keycloak that is easier to work with in containers? Thanks! Cheers

[koonpeng]

@Achllle I'm sorry that my comment is interpreted as being rude, that it is not my intention. We do make efforts to make this repo more friendly to contributors, for example we have been making efforts to move frontend components to the react-components package, you should be able to run it on any OS with nodejs available, you can use npm run bootstrap -- packages/react-components to just bootstrap that package.

Technical challenges aside, running keycloak in docker is specifically because we do not want to "pollute" the host OS, if we run keycloak natively, it may help users like you who prefers to develop in docker, but it hurts other user's who like to develop on the host.

The problem with developing the full dashboard in docker is simply because I don't have a solution for it. I have tried doing it before briefly with varying levels of success and I wasn't able to find a way to support it without comprosing an user's preferred workflow. For example, I like to use vscode, you can run it "in docker" with the remote container extension, or you can run it "natively" in docker by setting up x11, user remapping, gpu etc in your container. For someone that prefers vim, it will involve a different set of challenges, which probably involve setting up a ssh server and connecting to it. As such, the problem of running a development environment in docker encompasses a much larger scale than this repo and it is not something anyone in the team have a solution for atm, the best bet is to dig into docker itself and learn about how it isolate containers, manage networks, how docker daemon works etc.

Echoing @codebot, I very much appreciate if you have suggestions on how we can make it easier to develop in docker.

[Achllle]

I see, that's helpful. I don't yet fully understand this particular repo and how it works (I'm not a frontend dev) and likely for that reason found it odd that there is a strong dependency on an RMF installation, even launching one of the demos (?). I would think that the app can be launched independently and simply fails to connect to RMF when it's not available.

you can use npm run bootstrap -- packages/react-components to just bootstrap that package. Does this mean it's possible to run the app without this RMF dependency? That would mean that I can keep the RMF installation snugly inside the container, run the app natively (with keycloak in a separate container) and open the right ports to connect the parts. Or am I understanding this wrong?

Regarding keycloak - I'd be curious if it's easy to run the app without it for development/testing purposes. If it's likely that it will remain a barrier to entry, this might be worth investigating. Imagine if you required RMF (demos) to work exclusively with SROS as opposed to the optional add-on that it is now, then some people might not get RMF to work because of that additional requirement.

[koonpeng]

I don't yet fully understand this particular repo and how it works (I'm not a frontend dev) and likely for that reason found it odd that there is a strong dependency on an RMF installation, even launching one of the demos (?).

Yes, this is one of the challenges we have to overcome. This started off as a frontend for rmf but we realized that this will not be enough with the requirements and goals we have in mind. Without a connection to rmf, we won't be able to display any information, we used to work around it by making use of mocks, but that quickly outgrow its usefulness as the scope of rmf-web grows. As it is now, rmf-web does not just aim to provide a frontend for rmf, it also aims to handle task commands, logging, health monitoring, alerts, analytics, authentication etc.

Does this mean it's possible to run the app without this RMF dependency?

The instruction to connect to an external rmf is here, https://github.com/osrf/rmf-web/tree/main/packages/dashboard#external-server. You need to follow the instructions at https://github.com/osrf/rmf_demos to start your own instance of rmf, then, you can configure the dashboard to connect to the server by following the instructions above. You need to start keycloak as well with npm run start:auth.

Regarding keycloak - I'd be curious if it's easy to run the app without it for development/testing purposes. If it's likely that it will remain a barrier to entry, this might be worth investigating.

Actually, running keycloak in docker is meant as a way to reduce the barrier of entry. The image we used is set up with the correct realms, keys, users etc so that you wouldn't have to worry about the steps to install and configure keycloak yourself, which would normally require multiple pages of instructions.

Keycloak is the only authentication provider we support right now, but it is possible to easily add support for new providers, https://github.com/osrf/rmf-web/blob/main/packages/dashboard/src/components/auth/authenticator.ts. You can implement a new authenticator and set it up in https://github.com/osrf/rmf-web/blob/main/packages/dashboard/src/app-config.ts to use it.

[codebot]

Good point @koonpeng , I wonder if for quick/easy startup, if we can provide a generic EverybodyIsAuthenticated type of provider? I guess it needs to hand out JWT's, but maybe there is a way to make a super simple minimalist provider that gives JWT's to anybody who asks for one. This wouldn't be useful for any kind of security, this would be just a placeholder to allow people to run local simulations as easily as possible.

[koonpeng]

@codebot That is certainly possible and should be quite easy to implement as well, actually we don't need to handle jwt if we just disable authentication in ros2-bridge as well. The downside is that you won't see authentication but this is probably less of a problem now that we have a dp3 deployment and we can use that for demos instead of doing it directly from this repo.