Nothing! This was added in 1.7.14. And pull requests are welcome if you find issues with it!
As to the whole story with containers - we found that you could already do this today in OOD and we didn’t need to add anything for the other desktops we run.
Here’s that topic in case you’re interested in it, but essentially it relies on the script_wrapper portion of the submit.yml.erb and a container of your choosing.
So the decision to run a desktop in a container is entirely your choice and configurable from our side. If you want to keep the desktop libraries on the host, that’s totally fine to do that and run KDE directly from bc_desktop.
My thinking with containers is more about giving user’s access to libraries that aren’t on the host (vs restricting access to resources like storage, though it does this just fine as well). And that seems to be the case with other users who wanted desktops in containers. Indeed even you indicate that your deploying desktop software to your compute nodes for the first time. I can run KDE at OSC through a container, even though we don’t have those libraries on the host! And I think that’s the big win. As to binding directories, that’s completely at your discretion for your use. For a desktop you’d probably want to have a fairly liberal policy (mounting most things), but really it comes down to whatever works for the user.
This could be a show stopper. I found this issue with singularity that seems to indicate you need to enable unprivileged setuid on the host. I can’t get it to work at OSC after spending a few minutes on it, so I’m sure you’d have to at least you’d have to do some fancy footwork to get it to work and at worst you’d need to modify your host system.