for training and courses, we want to give the participant and students a locked down version of generic apps, where we hardcode eg the cluster they can use, the number of nodes, the reservation but leave everything else the same.
for now, we simply copy the original generic app, and modify eg the manifest (the app appears as a dedicated app in a courses subcategory) and the form; but leave all other code untouched. with linux permissions based on groups, we make sure only the people who need the app actually see it.
this is all nice, but is a maintenance nightmare. is there another/better way to sort-of subclass an app directory (or what have others hacked together to deal with this)?
I think the best you can do is have a skeleton app with the files you don’t change and the minimum common code in the files you do change which then added to with the changes you need. Given you only need to change some form and manifest entries that doesn’t seem too hard, is there something else I’m missing here.
yes, i was already considering to write some code to generate the apps based on templates/skeletons. but before i started to write more code, i was merely checking if there was something existing in the ood framework itself that i could use for that.
wrt the autovariables, no that is not relevant. we already generate the yaml with some ruby code in the form.yml.erb
We have special apps for this use case. You can see the same below. The trick is we hold a lot of metadata/config data in cluster.yml files that the app reads. So when a new class comes online, we just edit the cluster.d/cluster.yml and the app just reads & reacts from that.
That said - there actually is a facility for subclassing apps (we call it subapps). bc_desktop is an example of this. We ship files to /var/www/ood/apps and you supply overrides (subapps) in /etc/ood/config/apps
the subapps sound nice, and are almost what we want.
say there is a generic jupyter app in the apps list where you can eg select the number of cores using a dropdown. what we want is an app named course123 that has a modified form where we fix the number of cores to 2, all while leaving the jupyter app untouched.
so it’s almost like a subapp, but leaving the original app still available.
i can have a look at how the app/local magic is implemented, and maybe support an inverted mode: so i make a course123 appdir, in that directroy i symlink localbutinverted to the jupyter app, and i customise the form in course123/form. the localbutinverted would then somehow give preference to the “original” app/form instead of the app/localbutinverted/form.
i read the app and sub_app code, and i don’t think it’s an easy patch to make teh localbutinverted thing to work. anyway, for now i’ll stick to some python code that generates the apps form tempalte apps.
it also looks like the sub_app code is limited to .yml or yml.erb (and .js files) processing, not to eg scripts templates/ (not that i need this, but that is not clear from the docs)
