Strategy for modifying the bc_desktop in production

Admission: I’ve managed ood at our institution for quite a few years now, and I’ve apparently forgotten everything I might have known about the bc_desktop app.

What is a best practice for implementing changes to bc_desktop form and submit script? Again, the goal is to not edit the production files (kind of an obvious goal).
I have previously taken the approach to use the linux mode and permission settings to create development files for the form and/or submit scripts. So for our Pioneer cluster, my production and dev files would be (imagine similar files for submit.yml.erb):

-rw-r----- 1 root hpcadmin 1858 Jan 19 2021 rider_dev.yml
-rw-r–r-- 1 root root 2026 Jan 13 2023 rider.yml

So by restricting the group to our ‘hpcadmin’, and of course also removing ‘read’ for other users, I am able to then (re)load the ood dashboard, and find the dev version in the ‘interactive apps’ dropdown menu.

  1. Are there better approaches than what I’ve tried to describe?

  2. The above approach is currently not working for the ondemand instance supporting one of my clusters. Setting permissions on a development file is not causing the dev form to appear in the interactive apps dropdown menu. What troubleshooting steps should I take to understand why reloading the dashboard fails to reread from /etc/ood/config/apps/bc_desktop?

Thanks in advance,
~ Em

Not really! I mean, asked another way, what approach is easiest to that I can move on to my other work duties and I think your approach is likely the simplest/quickest for you to be able to test and then move on to whatever else is going on at your center. The approach we use at OSC is actually more complicated, with I would argue, no real benefit other than possibly someone seeing that desktop when they shouldn’t (i.e., someone mistakenly issuing chown/chmod those files).

If I had to guess - I’d guess there’s something simple/obvious that you’re missing. Some simple copy/paste error like the cluster is configured to be A when it should be B or invalid YAML.

You can try this as a spot check - navigate to the URL that you’d expect. There’s no link to the application as you indicate, but if you navigated there by manually editing the URL of your browser - you may get some error message that indicates why it’s not showing up.

So if you can navigate to rider - edit the url to be rider_dev and see what happens.

Thank you, Jeff! In other words, if my development form has syntax error(s), it won’t be recognized as a valid option? I just copied and renamed the production form to test this idea, and after updating mode and group ownership, reloading the dashboard presented the new “test” desktop in the dropdown menu, and the form opens at the appropriate url.

So now I can try and pick up my development activities from many months ago…or perhaps just start over. But those are my issues.

Nonetheless, thanks for.helping me to through to the underlying problem.

Best wishes
~ Em

I would have to lookup the code to be 100% sure, but yes, I would expect that behavior. I.e., it’s better not show anything at all than to show something that doesn’t/can’t work (at least IMO).