I’m experimenting with the Project Manager, and based on what I can tell, there is a limited number of pre-defined scheduler parameters that I can choose from when adding variables. Specifically, here is what I see in our version of the project manager (OOD v4.0.2):
Hours
Queues
Account
Job Name
Log Location
Nodes
Environment Variable
Cores
We have some less-commonly-used scheduler parameters that we supply for our interactive apps using the native directive in the submit.yml.erb. Is there an analogous method for the Project Manager?
From the little I’ve been able to gather, with the Project Manager, the user does not have as much control over the submission command (in our case, qsub) as we do with the interactive apps framework in submit.yml.erb.
You can use #SBATCH directives for things outside of what the UI provides.
There is a form.yml that I’d imagine you could hack - but manual edits will get overwritten if you edit the form in the UI.
We’re trying to remove the need to know YAML and the syntax of native/submit.yml.erb or similar. This is something admins struggle with, so we’re not trying to push this knowledge requirement to end users as well.
Sure, I think that makes sense. So the idea is that if someone wants to do anything more elaborate than what’s in that list, they need to hardcode it with #SBATCH directives by editing the job script?
Obviously you can’t support an endless list of options in the UI, but how do you anticipate taking requests for additional fields? For example, there’s no option for GPUs, but that seems like something fairly common that people might want. Or what if someone wants an email when their job starts and stops?
I guess where I’m going with this is, with the current architecture, you do shield the user from having to interact with yaml and erb, but if they want to do something that’s not in the list, they’re back to editing backend scripts, which is what we were trying to shield them from in the first place. I suppose you could say that more people are more comfortable with bash than with yaml/erb. But in principle, even for very basic use cases, it feels like the UI does not take you all the way to a functioning workflow.
I suppose my version of the Project Manager could have fewer features because we’re several bug fix versions behind latest release too. I know you’re working on a lot of things for 4.1.
Some things have been added yes, but there are still many more to do.
Basically we just need to build out the infrastructure for auto_ related fields. For example we need to query the scheduler and build lists automatically like we do for auto_accounts or similar.
In any case, this is a replacement for the Job composer which only has 4 (I think?) hard coded fields and everything else has to be defined in scheduler directives. So I think it’s at least an improvement on that.