WAS buttons on clients tab
bert269 opened this issue · comments
Hi
I do not know the exact process/procedure to follow, but do you think that it will be possible to disable some of the buttons, while another process in busy. For instance: When I press the "Apply config" button - all the other buttons are avaialble too. Does this mean I can press the OTA button to apply a newer version of the software? Or can I press the "apply NVS" as that is also avaialble.,
When I function is busy, can we perhaps diable the other buttons for this device while it is busy applying the selected option or are in the process of rebooting. I do notice that the device dissapears from the list when rebooting. I think it makes it less confusing.
Also, it seems that the order of the devices changes at random. When I select a device to apply the config too, before I press the next button I have to ensure that it is still the device I was busy with, else another shows up at exaclty the same spot. Very confusing.
Maybe assign a number to each and keep the order - or keep the labels in a specific order?
Jsut thought I'll share the request.
We have completely revamped the UI with a modern React web frontend and much of this is handled there. It will be the default in the next WAS release. The current Streamlit UI was just a placeholder to have something while we built the much more capable (but complex) React version. We're not frontend/web people so we had to call in some favors :).
Generally, the device has a failsafe mechanism so that actions like apply config, nvs, restart, etc aren't dangerous when you rapidly click follow-up actions.The device immediately drops the connection to WAS after the command so no matter what you do in the UI the device won't action on it. The new UI also correctly reports the status with a notification of the commands so you will get feedback when a command succeeds/fails. Also because the UI renders dynamically when the device is processing a command it disappears more or less immediately.
The new UI also has much better state management, auto-load/reload, etc so the general device appearance, behavior, etc is more consistent with what you are describing.
In addition, the new release of WAS (timed with the web UI) will always return devices/clients in consistent order. The problem with just sorting by label name is that labels are optional so this presents some interesting design questions.
The current version of the web ui still "jumps" a little as they appear/disappear but we're also working on "greying out" devices that were connected but are no longer connected (then re-enabling them when back). We're also going to eventually have the standard "sort by" options in the UI so you can sort by label name, hostname, last connected, hardware type, software version, etc.
@bert269 - Have you tried this again with the latest WAS release? The latest WAS release includes the new web user interface I was referencing above. When you request actions that initiate a device restart the device drops from the connected clients interface immediately. Additionally, the devices are now all sorted alphabetically by device label if it exists on all devices and hostname otherwise.
@kristiankielhofner - Thank you. No I have not had time to try the new version yet. I will see if I can get to this today and let you know. It sounds very, very impressive.
I stopped WAS and run the command as per in the github page. I cannot connect to this container now. I get the message"site not found" I cleart the cookies in the browser, restarted and try again - still cannot connect. Did teh port change? I'm still using 8501.
Thanks
8502 is not working either
What do your WAS logs show in the container?
I do appologize. I am a total noob when it comes to docker and containers. It's a mirrible I got this far.
These are the messages I am getting installing and running and also to displaying my running containers:
Cloning into 'willow-application-server'...
remote: Enumerating objects: 1294, done.
remote: Counting objects: 100% (840/840), done.
remote: Compressing objects: 100% (335/335), done.
remote: Total 1294 (delta 555), reused 665 (delta 496), pack-reused 454
Receiving objects: 100% (1294/1294), 215.33 KiB | 1.15 MiB/s, done.
Resolving deltas: 100% (760/760), done.
bert@wis:~/willow-application-server$ sudo ./utils.sh run
Using default configuration values
WAS Web UI URL is http://192.168.1.239:8502
[+] Running 1/1
✘ was Error 1.0s
Error response from daemon: pull access denied for willow-application-server, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
bert@wis:~/willow-application-server$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c286b631ba17 vaultwarden/server:latest "/start.sh" 11 days ago Up 11 days (healthy) 3012/tcp, 192.168.1.239:1025->80/tcp vaultwarden
e6e2615c70f4 nginx:1.25.0 "/docker-entrypoint.…" 2 weeks ago Up 22 hours 80/tcp, 0.0.0.0:19000-19001->19000-19001/tcp willow-inference-server-nginx-1
d6837cecfd84 willow-inference-server:latest "/opt/nvidia/nvidia_…" 2 weeks ago Up 22 hours 0.0.0.0:10000-10050->10000-10050/tcp, 19000-19001/tcp willow-inference-server-wis-1
0de9b10b44c9 portainer/portainer-ce:latest "/portainer" 2 months ago Up 11 days 0.0.0.0:8000->8000/tcp, :::8000->8000/tcp, 0.0.0.0:9443->9443/tcp, :::9443->9443/tcp, 9000/tcp portainer
bert@wis:~/willow-application-server$
How do I look at the logs. Portainer does not show it if it's not running - is there a log file somewhere?
There is not a log for this container in /var/lib/docker/containers - as I assume it is not started.
Are you on the main branch? That message is saying you are trying to pull a docker image from somewhere but you were denied access.
Also if you are just using docker, it may be easier to run the prebuilt docker container using the command referenced here:
https://github.com/toverainc/willow-application-server#running-was
When you ask if I am in the "main branch" - I assume you mean if I am in the "willow-application-server" directory - yes I am.
Using configuration overrides from .env file
WAS Web UI URL is http://192.168.1.239:8502
[+] Running 1/1
✘ was Error 1.0s
Error response from daemon: pull access denied for willow-application-server, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
bert@wis:~/willow-application-server$
Let me give the local install a try. I have tried that a few months ago, it failed and then went back to docker. Will keep you updated.
No I mean what branch you have checked out, if you do git branch -v it would show in green. You should be on main, I think in the past people were on wasng but that no longer exists. :)
I do not know - I copied the command from the github page. It should be main.
This is the result of trying to run WAS after the build:
bert@wis:~/willow-application-server$ sudo ./utils.sh run
Using configuration overrides from .env file
WAS Web UI URL is http://192.168.1.239:8502
[+] Running 2/2
✔ Network willow-application-server_default Created 0.1s
✔ Container willow-application-server-was-1 Created 0.0s
Attaching to willow-application-server-was-1
willow-application-server-was-1 | Traceback (most recent call last):
willow-application-server-was-1 | File "/usr/local/bin/uvicorn", line 8, in <module>
willow-application-server-was-1 | sys.exit(main())
willow-application-server-was-1 | ^^^^^^
willow-application-server-was-1 | File "/usr/local/lib/python3.12/site-packages/click/core.py", line 1157, in __call__
willow-application-server-was-1 | return self.main(*args, **kwargs)
willow-application-server-was-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^
willow-application-server-was-1 | File "/usr/local/lib/python3.12/site-packages/click/core.py", line 1078, in main
willow-application-server-was-1 | rv = self.invoke(ctx)
willow-application-server-was-1 | ^^^^^^^^^^^^^^^^
willow-application-server-was-1 | File "/usr/local/lib/python3.12/site-packages/click/core.py", line 1434, in invoke
willow-application-server-was-1 | return ctx.invoke(self.callback, **ctx.params)
willow-application-server-was-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
willow-application-server-was-1 | File "/usr/local/lib/python3.12/site-packages/click/core.py", line 783, in invoke
willow-application-server-was-1 | return __callback(*args, **kwargs)
willow-application-server-was-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^
willow-application-server-was-1 | File "/usr/local/lib/python3.12/site-packages/uvicorn/main.py", line 416, in main
willow-application-server-was-1 | run(
willow-application-server-was-1 | File "/usr/local/lib/python3.12/site-packages/uvicorn/main.py", line 587, in run
willow-application-server-was-1 | server.run()
willow-application-server-was-1 | File "/usr/local/lib/python3.12/site-packages/uvicorn/server.py", line 61, in run
willow-application-server-was-1 | return asyncio.run(self.serve(sockets=sockets))
willow-application-server-was-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
willow-application-server-was-1 | File "/usr/local/lib/python3.12/asyncio/runners.py", line 194, in run
willow-application-server-was-1 | return runner.run(main)
willow-application-server-was-1 | ^^^^^^^^^^^^^^^^
willow-application-server-was-1 | File "/usr/local/lib/python3.12/asyncio/runners.py", line 118, in run
willow-application-server-was-1 | return self._loop.run_until_complete(task)
willow-application-server-was-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
willow-application-server-was-1 | File "uvloop/loop.pyx", line 1517, in uvloop.loop.Loop.run_until_complete
willow-application-server-was-1 | File "/usr/local/lib/python3.12/site-packages/uvicorn/server.py", line 68, in serve
willow-application-server-was-1 | config.load()
willow-application-server-was-1 | File "/usr/local/lib/python3.12/site-packages/uvicorn/config.py", line 467, in load
willow-application-server-was-1 | self.loaded_app = import_from_string(self.app)
willow-application-server-was-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
willow-application-server-was-1 | File "/usr/local/lib/python3.12/site-packages/uvicorn/importer.py", line 21, in import_from_string
willow-application-server-was-1 | module = importlib.import_module(module_str)
willow-application-server-was-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
willow-application-server-was-1 | File "/usr/local/lib/python3.12/importlib/__init__.py", line 90, in import_module
willow-application-server-was-1 | return _bootstrap._gcd_import(name[level:], package, level)
willow-application-server-was-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
willow-application-server-was-1 | File "<frozen importlib._bootstrap>", line 1381, in _gcd_import
willow-application-server-was-1 | File "<frozen importlib._bootstrap>", line 1354, in _find_and_load
willow-application-server-was-1 | File "<frozen importlib._bootstrap>", line 1325, in _find_and_load_unlocked
willow-application-server-was-1 | File "<frozen importlib._bootstrap>", line 929, in _load_unlocked
willow-application-server-was-1 | File "<frozen importlib._bootstrap_external>", line 994, in exec_module
willow-application-server-was-1 | File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
willow-application-server-was-1 | File "/app/api.py", line 206, in <module>
willow-application-server-was-1 | app.mount("/admin", StaticFiles(directory="static/admin", html=True), name="admin")
willow-application-server-was-1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
willow-application-server-was-1 | File "/usr/local/lib/python3.12/site-packages/starlette/staticfiles.py", line 57, in __init__
willow-application-server-was-1 | raise RuntimeError(f"Directory '{directory}' does not exist")
willow-application-server-was-1 | RuntimeError: Directory 'static/admin' does not exist
willow-application-server-was-1 exited with code 0
what is the output of git branch -v ?
Actually, I think your problem is that when building WAS locally like this (really intended for developers) you'd also need to build the UI locally and add that in, as they are separate code areas. For your uses I think you would be better off stopping this container (./utils.sh stop), and instead running the precompiled container:
docker run --detach --name=willow-application-server --pull=always --network=host --restart=unless-stopped --volume=was-storage:/app/storage ghcr.io/toverainc/willow-application-server
* main e486487 README: drop main tag from container image
That is what I was going at first - running the pre-build container and it was working fine, until this morning - when I tried to run the updates. THAT is when I tried to do the local build and that failed then too. I will stop this, and go back to the pre-build. bot for some reason I cannot logon to that at ports 8501 / 8502. Will post the output from that
I stopped the local build and deleted the directory.
Then I run the above command:
latest: Pulling from toverainc/willow-application-server
a803e7c4b030: Pull complete
bf3336e84c8e: Pull complete
7fec366bd7fe: Pull complete
1a22e9af4e7a: Pull complete
b07e90d14538: Pull complete
98d9cfa78a29: Pull complete
67c69d3b530b: Pull complete
6fd51b9e5c6a: Pull complete
e10ff8e875d2: Pull complete
0b592f2b856e: Pull complete
abef720f3cd3: Pull complete
3d502888fd5c: Pull complete
7676f48d9cf1: Pull complete
Digest: sha256:faa8d6aaa5bd4c3b1b7e14196c3a2ccdd2e0d3b6651802821a215828a3a3c13e
Status: Downloaded newer image for ghcr.io/toverainc/willow-application-server:latest
e5fd23e88cd9821fb0f97755dcdd9c75fc316752f40a0bddb269f64332926184
Listing the running containers:
```bert@wis:~$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e5fd23e88cd9 ghcr.io/toverainc/willow-application-server "/bin/sh -c /app/ent…" 58 seconds ago Up 56 seconds willow-application-server
c286b631ba17 vaultwarden/server:latest "/start.sh" 11 days ago Up 11 days (healthy) 3012/tcp, 192.168.1.239:1025->80/tcp vaultwarden
e6e2615c70f4 nginx:1.25.0 "/docker-entrypoint.…" 2 weeks ago Up 23 hours 80/tcp, 0.0.0.0:19000-19001->19000-19001/tcp willow-inference-server-nginx-1
d6837cecfd84 willow-inference-server:latest "/opt/nvidia/nvidia_…" 2 weeks ago Up 23 hours 0.0.0.0:10000-10050->10000-10050/tcp, 19000-19001/tcp willow-inference-server-wis-1
0de9b10b44c9 portainer/portainer-ce:latest "/portainer" 2 months ago Up 11 days 0.0.0.0:8000->8000/tcp, :::8000->8000/tcp, 0.0.0.0:9443->9443/tcp, :::9443->9443/tcp, 9000/tcp portainer
Trying to access it:
Looking a the docker ps output - it does not seem that there is a port connected to this container, compared to the others:
e5fd23e88cd9 ghcr.io/toverainc/willow-application-server "/bin/sh -c /app/ent…" 58 seconds ago Up 56 seconds willow-application-server
c286b631ba17 vaultwarden/server:latest "/start.sh" 11 days ago Up 11 days (healthy) 3012/tcp, 192.168.1.239:1025->80/tcp vaultwarden
e6e2615c70f4 nginx:1.25.0 "/docker-entrypoint.…" 2 weeks ago Up 23 hours 80/tcp, 0.0.0.0:19000-19001->19000-19001/tcp willow-inference-server-nginx-1
d6837cecfd84 willow-inference-server:latest "/opt/nvidia/nvidia_…" 2 weeks ago Up 23 hours 0.0.0.0:10000-10050->10000-10050/tcp, 19000-19001/tcp willow-inference-server-wis-1
Per the instructions it would be http://192.168.1.239:8502/ :)
The server runs in host mode so no explicit port maps are needed like the others.
oh, ok. THAT was the problem - I tried to acces it via 192.168.1.239:8502 and not 192.168.1.239:8502/ ...... DUH, I am so sorry that I wasted your time. THe little things!
For some reason it was still in my cache, NOW it is working and looks very professional. Thanks for your help.
I will flash a box-lite and report back.
Again - thank you
Great, glad it is working! :)