Our installation is working nicely with Mate and Xfce. Some of our researchers have a strong preference to work in KDE. I don’t find any mention of KDE in the documentation or in Discourse. Is anyone able to address possible plans to add KDE to the distribution, or to offer advice for how to implement KDE through a custom-built interactive application.
Thanks
~ Em
Em,
I’ll look into putting together an example on how to add KDE.
Hi, Morgan – Thanks for the encouraging note.
Best wishes,
~ Em
@emily.dragowsky I just finished working on an example KDE implementation and have posted it to Github. For the time being it is a standalone Batch Connect application and is not integrated into the official bc_deskop. If it works well, then we will probably consider it for inclusion in the main OOD distribution at some point.
Have a look at that and let me know if you have any questions.
- Morgan
Thank you, Morgan – I’ll be able to pickup with studying your much appreciated work next week.
Best,
~ Em
Has this been working well? I wonder if we should look into merging it? or at least beta testing it at OSC?
Hi, Jeff, Morgan –
Here at CWRU, KDE Desktop as an independent app was finally implemented this spring, following Morgan’s work. The app has drawn the interest of a lead data science faculty member, and is so far viewed positively. Our cluster management have decided to deploy desktop software on our compute nodes for the first time, so we are now using Xfce and MATE through the bc_desktop, and KDE through a separate app.
I read with interest the plans to implement a KDE container through the 1.7.13 release. Moving KDE to production makes sense; however, what prevents implementing KDE through the bc_desktop? The distinction is leading me to think of presenting separate interfaces for the MATE and Xfce, so that all three options appear in the Interactive Apps menu/list, even though KDE appears as a ‘server’, rather than a ‘desktop’.
Please help me to understand the KDE container implementation: How is this container implementation meant to access cluster resources? Our view of containers is to provide distinct, specialized environments, with minimal binding of the host system storage resources. Perhaps we need to think differently?
Maybe more concretely, the data science faculty with the interest in KDE already takes a container-based approach to computation on various resources, including our HPC cluster. I’m not very knowledgeable as yet about containers, but it seems that a container KDE desktop would not support running another container within it, and so would not be as general as, say, a KDE x2go desktop session.
Sorry for the lengthy gap in attention to this topic. I look forward to gathering thoughts.
~ Em
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.
Hi, Jeff –
It would seem that the containers are less constraining than I thought. And so is it true that within the container, the cluster environment may be preserved? By which I mean, access to slurm, to all the installed software, to the module system for managing the environment? I find I’m having a hard time expnding my previous view of containers, and how they present an environment that is separate from the host. What I take away from your note is that any constaints on the container are not requirements, and the container may be built to have full access to the cluster resources.
On a pragmatic note, I suppose I need to upgrade and try it out. I tried to follow the MATE container thread, but am not convinced that I understand the specifics of implementing containers for the Desktop. Can you help point me to some documentation for that? Or does one proceed largely by analogy with the RStudio interactive app? I’ve only seen the “script_wrapper” used in interactive apps, though what you’re saying is that it has been included in the bc_desktop app as of 1.7.14?
Thanks
Re: script_wrapper, I meant to indicate that the only example I can find in my 1.6.22 install is from the optional KDE desktop interactive app.
The only thing added in 1.7.14 is the kde file was added to bc_desktops. script_wrapper has been around for some time, I’m sure. So you won’t need to upgrade, just start working on a sandboxed bc_desktop.
Yea the world of containers is crazy, but it’s essentially this: through configuration you can mount in any directory or file from the host (or all of them if you like). And that’s just through configuration, not even really the building of the image - just the running of it. Singularity specifically does overlay and underlay, so it’s more like a merge of the two filesystems than an outright overwrite (here’s a blog entry I found helpful: https://jvns.ca/blog/2019/11/18/how-containers-work--overlayfs/).
Clearly containers are a very large topic, but yes, you can preserve the environment in a container though some amount of configuration (painful or otherwise).
But to the MATE container topic unfortunately that’s the only documentation we have on it (that topic). I think the 21st message or the 32nd messages are good to focus on.
Basically the strategy is this: We have all this functionality to configure and launch desktops in the script itself. This is the script that get’s sent to the scheduler. But we want to launch that script in a container. So in the script wrapper we can write it all out to a different file (effectively copying the file) and launch that file in a container that has all the appropriate libraries (MATE, KDE etc).
So the script that gets executed by the scheduler is effectively something as simple as this. We create a file called container.sh and launch that file in a container.
#!/bin/bash
cat << "CTRSCRIPT" > container.sh
# ... all the stuff we need to configure and launch a desktop
CTRSCRIPT
singularity run myimage.sif /bin/bash container.sh
Hope that helps!
Thanks, Jeff – I think this will keep me occupied for a bit.
Appreciated!