(Click to open topic with navigation)
Nitro is an HTC scheduler application executed by a job script just like any other application a user might execute. By design, Nitro does not and will not perform scheduling functions like a regular system scheduler, such as, enforcing per-user, per-group, and/or per-account resource or usage limit policies, supporting fair-share policies, maintaining separation between users in a multi-tenancy environment, etc. This means Nitro will not perform functions such as launching tasks from one Nitro job as different users, etc.
1.4.1 Nitro and Users
If users are subject to different constraints and policies, requiring the users to submit their own Nitro jobs and not combine the Nitro tasks allows the system scheduler to enforce policies on the users, which is the system scheduler's responsibility. Thus with Nitro, the administrator will continue to use the system scheduler to enforce policies in the normal manner.
For example, if three users (A, B and C) each want to execute Nitro tasks that are the same application and perhaps even use the same data, they each must submit their own Nitro job with its own task file (could be the same file but the users must specify it for their own job). If they are each subject to different policies and constraints, the system scheduler enforces those constraints and, by design, Nitro is ignorant of the policies and constraints and will remain so.
1.4.2 Nitro and Host Resources
If a user wants to execute workloads that require certain hardware resources or constraints, the user must use the system scheduler's resource request capabilities to allocate or constrain such.
For example if a Nitro job will execute workloads that require an accelerator, such as NVIDIA/AMD GPU or Intel MIC (Xeon Phi), the user must request hosts with the required accelerator(s) for the Nitro job so the workloads have accelerator(s) available to them.