I compared vnc.log and output.log when Desktop App started with OOD 2.0.32 and when Desktop App didn’t start with OOD 3.0. But, it seems that there is no difference between the two except that it is interrupted in OOD 3.0.
Were the compute nodes also upgraded to Rocky 8 or was it just the webnode?
Could you supply the node_uri and rnod_uri from the ood_portal.yml as well? And lastly, could you open this in Chrome, open a new tab with the developer tools open and see if there are errors in the console and also check the response of the request (which will be under the Network tab in the dev tools).
Were the compute nodes also upgraded to Rocky 8 or was it just the webnode?
I am using the Singularity container and its OS is Rocky 8.7. Also, the host running the Singularity container has the same OS.
Could you supply the node_uri and rnod_uri from the ood_portal.yml as well?
node_uri: '/node'
rnode_uri: '/rnode'
And lastly, could you open this in Chrome, open a new tab with the developer tools open and see if there are errors in the console and also check the response of the request (which will be under the Network tab in the dev tools).
Got hit by this too, and took about 2 hours to troubleshoot before I got to this thread. Jeff/Travis, can you please add this to the OOD 3.0 update instructions somewhere for others to notice quicker?
Travis, please, also specifically say that one needs to use websockify 0.10.0 or newer, the 0.8.0 is using python 2, and that’s what we’ve been using till now. 0.10.0 is using python 3. I think if you explicitly mention websockify it’ll hit people more than just saying that python 3 is required.
Hmm, I think I need some feedback here as a developer. How are people installing websockify? I ask because I can’t quick understand how this situation is coming about if one used python3 and pip. Are these manual builds and this is why the dependency is never checked? I want to make sure I understand how this is being put together because I personally would prefer the package manager to deal with that than have the docs call out a specific version, when that version is already the default if you are using the correct version of python.
Essentially, I am trying to understand how this mismatch showed up and what the workflow for building this looks like to users.
We hand install websockify into our apps tree (which is separate from the OS installed rpm packages). We only install rpms from the official Rocky 8 channels into the OS, which is why we have the websockify separate. If most sites install it via rpm into the OS (or if they get it from your repo or EPEL - if it’s there), then I suppose it does get updated with the OOD update and all is good. It just did not happen with our update.
So maybe this is not as common of a case, but, looks at least 3 sites (incl. us) did get hit by it.
Thanks Martin, I’m trying to make sure I write this in a way to capture all this. I’ll include a line about the websockify version as well and will have a Danger banner over those upgarde instructions with the information.
Just to add our experience, we are running CentOS 7 and upgrading from OOD 1.3 to OOD 3.0.1 and ran into what I think is essentially the same issue with websockify.
We were running python-websockify 0.8.0 which resulted in a noVNC unable to connect using OOD 3.0.1, but on updating the cluster to python3-websockify 0.10.0 everything works fine with OOD 3.0.1 which we should have deployed to production next week. We did not need to update TurboVNC or any other packages as we already install python36 from EPEL on all our CentOS7 nodes.
I would also note that python3-websockify 0.10.0 appears to be fully backwards compatible with OOD 1.3, so which makes the upgrade procedure operationally smooth for us (so far).
to OOD 3.0.1 and ran into what I think is essentially the same issue with websockify.