epmog
commented
7 months ago We can definitely move to quickly add env variable support to the submitters to allow easy env management for the initial settings (sticky would then take priority like they currently do). We're just going to have to settle on the env variable template and add it to all of them.
DO NOT MERGE.
I intend for this PR to spur discussion on improvements in this problem area with a concrete example of a potential solution. This PR should not be merged, most of all because I haven't even tried running this code yet.
What was the problem/requirement? (What/Why)
The current submitter paradigm has a few areas that can be improved.
Chief among them is that there is no easy way for a customer to dynamically and programmatically change the packages this submitter defaults to, absent the user manually editing that package list on submission.
What was the solution? (How)
While a config file might be used to solution here, referring to environment variables is a tried and true solution which likely meshes nicely with our customers existing solutions. If a customer is using a package environment configuration tool like rez, setting the below environment variables would be trivial. Customers could also cause
$ADC_REZ_PACKAGESto equal$REZ_USED_RESOLVE, resulting in a 1 for 1 match with the submission environment. This assumes the customer has the same rez packages available to their queue environment. This would be highly desirable for most large customers.What is the impact of this change?