What If we combined Job Templates and Interactive App Forms?

Howdy! I’m Richard.

I have been quietly learning OOD for about a year and joined discourse today to ask this question.


I am a user support specialist for a research university. I try to bridge the gap between the clueless Users and the overworked Administrators.

I want the Users to adopt the new, better ways of doing things, but they won’t do it unless I can make it very easy. They don’t want to learn how the cluster works, and they shouldn’t have to. You can open up a Jupyter Notebook in about two clicks on Google Colab with zero understanding of Google Cloud services. That’s what we are competing with now. Every time I open up the Jupyter Notebook interactive app on our OnDemand instance and see how many form elements I have to scroll past (without reading) to find the the submit button, it makes me sad. And the cluster hardware sits idle. We can do better than this!

On the other hand, the Administrators don’t have time to keep updating each and every App form whenever a new software update is available. All the Apps work differently, and all the users want different environments, so the workload grows exponentially. Developing these Apps can get really hard because the more things we try to support the more complex the Apps become. Another university was impressed with something I built and it was just one feature for just one app. And we can’t even share it with them! Because no two sites are doing things the same way. We find ourselves re-developing the same things over and over while other people do the same. It’s madness.

So I’m basically trying to solve all the world’s problems. Thank you for attending my TED talk.

Two Problems

I noticed that Open OnDemand has a “Job Composer” feature. I think it’s really neat that we can interact with our scheduler without using the command line. The problem with Job Composer that it doesn’t actually succeed at reducing the user’s workload. In order to make the Job Composer do anything, you have to first write a functional batch script by hand. Doesn’t that kind of defeat the purpose? The user still has to learn how to use the scheduler and the module system, and they still have to type code by hand. Yes, this solution reduces the amount of manual labor - but it does nothing to reduce the barrier to entry for a beginner user. The New Template form in the Job Composer should have form fields for selecting scheduler options and modules. We already know this is possible, because our Interactive Apps do it that way.

I noticed that Interactive Apps have forms that allow the user to select their scheduler options and modules. I think it’s really neat that the user can select curated default values for quickly getting a functional job started. The problem is that this type of interface isn’t scalable. There’s no way for the User to save their combination of choices, if they want to switch back and forth between two combinations, between two apps, across clusters, or share with other Users. And every time the User wants something new that the current form field doesn’t support, they have to wait around until the administrators feel like updating the form. Yes, this solution reduces the barrier to entry - but it does nothing to reduce the manual labor. The Interactive Apps should have a consistent method of saving and loading scheduler and module options. We already know this is possible, because our Job Composer does it that way.

One Stone

What if… ? We could “Factor Out” the common scheduler and module form fields from the Interactive Apps, replacing them with a uniform “select a template” field. We then collect all of that logic and put it in the New Template form in the Job Composer. Maybe there are multiple New Template forms to help distribute the logic. In this paradigm, the Administrators would provide their Useful Preset Combinations for the Interactive Apps in the form of Default Templates. Each App would allow the User to choose from the list of default templates and user templates, perhaps filtered to show the relevant ones. The App Form wouldn’t function much differently for a casual user (who doesn’t read anyway).


TLDR: What if we insert “Job Template” way of doing things between the “select your options” and “submit interactive app”? This would unify lots of apps and help on-ramp users.

I understand that there are both technical and conceptual difficulties, but I do not fear them. My questions are:

  1. Is there a planned change to the core engine that will render this discussion obsolete?

  2. Is anybody already working on a similar solution to these problems?

  3. Does anybody have a better idea?


Thanks for the very interesting post and proposal. I’ll leave it to my colleagues @travert and @jeff.ohrstrom to chime in on the technical details. In reading through it, a few things popped to mind that I wondered if you are aware of or not (we know we have a big issue with having a lot of undocumented features / configs / etc).

  1. At OSC we have ‘system templates’ available for ALL our software packages in job composer. If you watch the live demo videos we have here I think I show this (Open OnDemand Walkthrough 200117 - YouTube). These are essentially ‘hello world’ versions of every software package that a client can click on and will run successfully with no modification. Then they can tweak them as their needs dictate.

  2. At OSC, we also deploy specialized versions of interactive apps that are ‘stripped down’. For example, we have our generic RStudio app that has a form where you can pick cores / runtime / etc. But we also have a ‘classroom’ RStudio app that doesn’t have those features, rather it’s hard coded to 1 core for 2 hours runtime (the needs for a typical classroom student). This app shows up automatically for clients based upon group permissions.

  3. We also have multiple OOD production instances at OSC. Our general (somewhat knowledgeable) clients log on to ondemand.osc.edu. But we point all our classroom students to class.osc.edu, which has very limited number of menus / buttons / etc they can click on, to give them more like the Google Colab experience you refer to.

  4. For some of our interactive apps we have ‘free form’ text fields that allow for certain arbitrary parameters to be passed to it. For example, in our Visual Code Server app there is a field for ‘working directory’ and in our Ansys app there is a field that allows you to point to a different license server.

Richard, I would love to set up a zoom to discuss this and bounce some ideas around. Would you be willing and have some time on Wednesday?

Would this be a candidate for discussion at the ‘office hours’? I’d be interested to either listen in or participate. I’m sure some others would like to follow the discussions as well.

1 Like

Sure, we may want to be prepared to dedicate some time to this topic outside of the office hour if there are others in the office hour with current issues looking for help vs this which may be a more forward looking topic.

Thanks, Robert. Wherever and whenever is fine. I thought it might be worth indicating an interest in the topic and in participating/hearing/seeing discussion. If there is a way I could get my name added to the list of attendees for those discussions for which a broader group might be appropriate, I would like to participate.

Hi Alan,

Re: 1. Nice video! Cool stuff in there. Some of it could become part of my solution.

Re: 2, 3, 4. These features clearly work well for their specific use cases. If we had just a handful of use cases, we would probably want to do it like that.

The strategies you described are not quite what I think we need. I would still like to pursue a new development.

Hi Robert,

Yes, I can chat on Wednesday. What’s your time zone?


Hi Bennet,

I would love to include you in the discussion. But the second Tuesday is so far away! Perhaps I could record the discussion for later review.


I am available any Wed.

There are ideas around this, although that’s about it. We haven’t really started to work on the next version of the job composer, but I’d say file feature requests and I’ll put them in this project to track.

Option profiles - that is, profiles for all the form options - I don’t think we’ve thought of yet, so I’ll file that ticket too.

Honestly, we get a lot of discourse topics and for us, the maintainers, it’s much easier to keep track of Github tickets. Especially when they’re in projects and labeled and so on.


Thanks for the heads up on the collapsible text!

job composer form builder · Issue #859 · OSC/ondemand · GitHub
New Job Composer Alpha · GitHub

This Wed at 1pm? Send me a pm if you are interested and I will send the zoom coords.

This is open to all, I just don’t want a zoom bomb.

1pm in <time zone>?

just to confirm, Bennet and I are in a zoom?

Howdy @rsettlag @bennet, I am sorry I missed our planned meeting yesterday. I was sick at home and forgot to check in.


Hi, no issues. Would you be available same time next week? 2:30 PM EST?

Yes, that will work.

Wednesday Nov 3, 2:30 PM EST

Look forward to the zoom invite! (as we have interest in the job composer and have discussed it with Jeff & Alan in the past.)

Will the Zoom link from last week be used again? If not, please include me in this week’s meeting.

I think I sent you a different zoom link, but Richard just joined this one: