Questions about bc_desktop

Get Help
1

Hi all,

I’ve got 3 questions about bc_desktop which got me confused.

  1. the files under /var/www/ood/apps/sys/bc_desktop are shipped with the ondemand rpm. However, the form does not specify a cluster, so it is invalid and not shown by default on the portal. If my understanding is correct, this directory gets parsed every time someone logs in and will fail by default. This seems wrong to me as it slows down the portal. Am I missing something? It seems to me this directory should not be included in the rpm.

  2. At our site we use xfce. Previously we already installed the bc_paraview app. Now when I look at how bc_paraview starts xfce and how bc_desktop starts xfce, these are completely different. For instance:

    • bc_desktop works in the user home dir, while bc_paraview works in the job directory.
    • bc_desktop starts xfce-session, bc_paraview xfwm directly without session management.
    • bc_desktop does not configure dconf, bc_paraview does configure it
    • …

    I’m wondering why the difference? Are there good reasons or is this just maintained by different people?

  3. in addition to previous question, is there a way to share the startup method of xfce between several apps? Most of our predefined apps will/should use the same way. I feels prone to error to copy the same files everywhere. Is there a way to source scripts/erb files/… from a common place?

2
  1. Yes, you’re right. But here’s the counter point - having zero clusters is the edge case. The more common case is you have at least one. So in the beginning while you’re testing, configuring, you have no clusters. But in the long run, when you’re in production serving customers you do. And as soon as you do have a cluster configured, then this application is immediately there and useful without you (or an administrator) having to pause and then think … OK got to install some other dependency.
  2. There could have been good reasons but if there are no comments indicating why so those choices are probably lost to the ether. Or maybe they’re documented in pull requests? But it’s unclear either way.
  3. I would suggest modules that you could load. Configure you’re cluster’s script_wrapper to load it like below.
  <snippet removed>

  batch_connect:
      basic:
        script_wrapper: "module restore\n%s"
      vnc:
        script_wrapper: "module restore\nmodule load ondemand-vnc\n%s"

Hope that answers some questions, though 2 may require some digging.

3

Your assessment that the form.yml in that directory gets read every time the menu is built by the dashboard is correct, and if there is no desktop config defined under /etc/ood/config/apps/bc_desktop then, even if a cluster is defined in the cluster config, these are wasted cycles. We are working on re-desinging the plugin architecture to do two things:

  1. expand capabilities to support batch work alongside interactive work
  2. address the many problems with the current solution (including what you identify)

If you have any suggestions please share on what would make life easier, or what you would like to do you cannot do now with the current plugins, please share.

The big difference between the Desktop and Paraview is Desktop launches a full desktop session, and Paraview just starts a window manager to launch only Paraview. We launch the other “GUI” apps like MATLAB and Abaqus and COMSOL in the same manner.

bc_desktop works in the user home dir, while bc_paraview works in the job directory

Where do you see this? In the latest master version it looks like we cd to the home directory.

I feels prone to error to copy the same files everywhere. Is there a way to source scripts/erb files/… from a common place?

Could you be more explicit about what you want to share? For example, in GitHub - OSC/bc_osc_paraview: Batch Connect - OSC Paraview case, might it be https://github.com/OSC/bc_osc_paraview/blob/5dcdbfcfaacea7e9b27357424340be12220aa0d4/template/script.sh.erb#L9-L22?

@jeff.ohrstrom’s solution for using the cluster config is good if you want to modify what goes before or after the job script body but this is not the same thing as the template/script.sh.erb which is executed as a child process. The cluster config modification also affects every vnc type interactive app.

There are several other options as well to share code or strings between apps (either in the form.yml.erb or the template/script.yml.erb) though the solution’s I’ve used before is not quite like using Rails partials.