Publish two docker images - one with TigerVNC, and one with TurboVNC?

[consideRatio]

I think it could be reasonable for us to build two separate docker images if we intend to support two VNC servers. This is a way to help ourselves test them as well.

Practically I'm thinking that we would allow a build arg to determine if the same Dockerfile builds to include TigerVNC or TurboVNC, and that we then build/push the image twice and varying the build arg.

Then, with such images in place, we could also do a simple smoke test for both TigerVNC and TurboVNC and resolve #68 in a relatively simple manner.

TurboVNC can be installed via apt as described here. I've confirmed that the apt installation method seem to be providing us with up to date versions of TurboVNC.

Suggested actions

• Add a vnc-server build arg defaulting to tigervnc, and refactor the Dockerfile to install TigerVNC towards the end, after everything else except copying of files from this repo to setup the Python package.
• Make TurboVNC be conditionally installed based on the build arg using apt according to official docs
• Add automation in github workflow smoke test the docker image using TurboVNC, and not only TigerVNC as we do now
• Add automation in github workflow to publish the TurboVNC image using a -turbovnc suffix to the tag
• Add automation in github workflow to publish the TigerVNC image like before but also using a -tigervnc suffix to the tag

[consideRatio]

@yuvipanda wrote in #87 (comment):

If #88 is enough for you to consider #68 resolved I'm very happy for the approach described in #88 to go forward.

---

@manics what do you think?

[manics]

Sounds fine to me!

I think it's worth deciding what the purpose of the images is though as this may affect how the Dockerfiles are designed. Are they production quality images that people should build on, or are they just examples for testing and development.

For example, in #77 (comment) there was a discussion about whether this should be an editable pip install or not (currently it is to optimise for development).

If it's not a production image, and therefore size isn't a concern, is it possible to install both vnc-servers and switch between them by changing the PATH or some other runtime argument? This also makes local testing easier.

[yuvipanda]

@manics I primarily think of the image as we have it as purely for development, as actual end users want applications in their containers.

[consideRatio]

I think the image could reasonably serve a purpose of:

• development
• example/demo
• base-image for desktop application images

I see some benefit and downside of installing both in the same image, and currently lean towards providing two separate builds. I figure with two builds we avoid developing some logic to switch between vnc server binaries, and avoid bloating the tigervnc image with turbovnc or the other way around, and that any application installed on top should pick a specific VNC server suitable for the applications installed, where I think for example OpenGL related applications may want TurboVNC rather than TigerVNC.

[psobolewskiPhD]

The 2.0 change log points to:
https://quay.io/repository/jupyterhub/jupyter-remote-desktop-proxy?tab=tags
But I cannot access this -- requires a signin.
Are these images intended to be not-public?
It would be useful to be able to test-drive the project or use them as a base image for a custom solution.

[consideRatio]

They were intented to be public, and that was the mistake - they were private! They are now public though, thanks for pinging about this @psobolewskiPhD!

[psobolewskiPhD]

Thanks @consideRatio !
I was able to pull it down (using apptainer actually) and run my app on HPC via TigerVNC! More performant than I expected!