You have to set up your placement rules to fulfill your specific need. In this example a
cluster is shared among developers, QA engineers and test developers and there are nine
placement logic that you want to set up.
The following is the placement logic that to achieve when creating placement rules:
If the user belongs to the devs primary group, the application should
be placed to root.users.devs. This is reserved for developers.
If the user belongs to the qa primary group, then the application
should go to root.users.lowpriogroups.<primaryGroup>. These queues
have lower capacities and are intended for testers.
If the user belongs to the qa-dev primary group, then the application
should go to root.users.highpriogroups.<primaryGroup>. These queues
have higher capacities and are intended for test developers.
Place the application into the queue which matches the user name.
If there is no such queue, take the queue from the application submission context, but
the queue should not be created if it does not exist and the parent is managed.
If none of the above matches, then the application should be placed into the
root.default queue.
If the default placement fails , change the default queue to
root.users.default.
Try a placement to the default queue again.
If that fails, reject the submission altogether.
Using the Queue Manager UI, this logic can be achieved in the following way:
Queue hierarchy
Queue with bolt signs next to their names are dynamic auto child creation enabled parents.
