-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Steps to run TagUI RPA on OpenFlow Cloud #7
Comments
PS - no hurry, only when you have time to look into this. Separately, I've replied your Telegram message on the Python issue |
I wrote on telegram for hints/help on what to look for to troubleshoot tagui :-) ... |
Below was my replies on Telegram. I see.. If running TagUI nothing happens other than Chrome opening a blank window, it could be for some reason unable to connect to Chrome. No curl command available, Chrome's websocket not allowed etc. Thanks for your inputs! let me try replicating and debugging from a Docker instance on my Mac laptop. TagUI and the Python rpa package should work across different Python versions whether 2.X or 3.X. lemme think what can be done to troubleshoot this. Does the problem happens for TagUI human language version or the Python rpa version? or both If it is the Python version only,
import rpa as r
/home/user/.tagui/src/samples/1_yahoo chrome To see if any other error messages can show up For Linux, TagUI will require curl command to be available. A possible cause might be curl command is no longer available. curl is needed by TagUI and the rpa package to search for the websocket connections at Chrome, so that TagUI can connect to it |
Curl is present. Wget too, that is what the image uses to get the zip files. |
Thanks Allan, I tried running below locally on my Mac and got the following cryptic errors when trying to run Chrome. Even with no parameters Chrome can't seem to launch successfully. The image used is https://hub.docker.com/r/openiap/nodered-tagui and I'm connecting to the terminal of the nice_leakey container.
|
Some links on this error message. Some approaches from Docker angle, some from Chrome angle. jessfraz/dockerfiles#350 When I tried below by adding --no-sandbox flag, the Chrome command runs. I remember for my Colab notebook, I have to run with --no-sandbox in order to launch Chrome as the root user. Could it be for some reason, previously the image is not running as the root user but is now executed as the root user? This train of thought is puzzling because
|
Could this be part of the solution ? Using chrome.json should be more secure than using sandboxing ( not sure why ? ) but if that is the solution i would recomend we inject it into the image, and make some option to tagui to tell it to use this file. I do not want to map it externally, is going to be a nightmare to support people on docker and kubernetes on how to add that file, so would be better if tagui could somehow detect the file or we can tell it somehow to use that parameter. Or we could go for the easy solution and just use --no-sandbox --headless ? what do you think ? |
In docker, you by default run as root. But in my dockerfile's I revert to an normal user, and is not running as root ( that is also why you used /home/openiapuser/tagui/src ) |
Hi Allan, I've booked your time on Friday 11am your time to troubleshoot this. In the meantime, that's interesting findings, the link that you shared - https://stackoverflow.com/a/64460373/17318661 Do you know what happened between previously when the image works and now? I'm trying to weigh what would be the best approach. From TagUI's perspective, using both chrome.json or --no-sandbox method requires the same hacks (modifying the tagui/src/tagui file). However, from TagUI's perspectively only, using --no-sandbox is the preferred method. This is because for at least 6 months, when I created the Google Colab versions of TagUI, --no-sandbox method has been used successfully. Thus, from usability perspective this method is most likely to cause less problems or edge cases failures for users. However, if we can confirm from Docker container perspective, using chrome.json is the best practice, then that should be considered as the approach to take. However, that may invite user support issues in the meantime because that path for TagUI has not been 'walked through' by big enough number of users. The solution to fix (what I did for the Colab notebook) is as part of the initialisation, make the modifications required in tagui/src/tagui file, so that either --no-sandbox is used or chrome.json is used by default. But in this case, it is tricky because there is the update option from Node-RED TagUI module. Any changes will be overwritten when that happens. On the other hand, to have
|
It's not better to use chrome.json in docker, it was just an alternative to using --no-sandbox ... if that works for you, then lets keep with that. |
Hi @skadefro yes this is a problem. TagUI in the execution script, does not have --no-sandbox. It has to be introduced in some way. For the Colab notebook examples, I introduced them by modifying the tagui/src/tagui file on initialisation of the cloud instance. But in this case, it is hard. Because any hack done will be gone when users choose the update checkbox in Node-RED. Unless as part of the update logic in Node-RED module, the modification is made post-update. Another solution would be introducing a new option for TagUI, for example |
Am chewing more on this... Catch you for the call later? |
Yup, we have a meeting in 2½ hour .. :-) |
Enhancement added in aisingapore/TagUI#1151 in TagUI v6.102 - By creating a dummy file (either blank or with text it's both ok) |
Done! Posted on LinkedIn a video demo - Showcasing this on TagUI GitHub - Showcasing this on TagUI usage guide -
|
Hi Ken, how are you? |
NodeRed can run as the user, or as a service. On Windows that means with access to the desktop and UI or not. |
Hi @marcelocecin good good, just overwhelmed with work and family commitments, and settling in. I just logged on to GitHub to see if there is any reported bugs on rpa package and saw your exchange above with @skadefro. Hope all is good with you. Been out of action from open-source community as I try to keep up with work and family. |
See a video demo of these steps, all the steps below should take under 5 minutes
Create OpenFlow Account
Create Node-Red Instance
Login to Node-RED on OpenFlow Cloud
Create an Example TagUI RPA Workflow
install node-red-contrib-tagui from Manage Palette
(top-right hamburger menu --> Manage Palette --> Install)
install node-red-contrib-image-output from Manage Palette
(top-right hamburger menu --> Manage Palette --> Install)
import example workflow for node-red-contrib-tagui
(top-right hamburger menu --> Import --> Examples)
Deploy and Run TagUI RPA Workflow
Spinning down the Node-RED instance
PS - This issue here was originally created to troubleshoot some rough edges with running TagUI on OpenFlow's Node-RED. The issues are now resolved, you can ignore the exchange between Allan and me and technical details below.
The text was updated successfully, but these errors were encountered: