Example - Placement rules creation

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:
  1. If the user belongs to the devs primary group, the application should be placed to root.users.devs. This is reserved for developers.
  2. 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.
  3. 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.
  4. Place the application into the queue which matches the user name.
  5. 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.
  6. If none of the above matches, then the application should be placed into the root.default queue.
  7. If the default placement fails , change the default queue to root.users.default.
  8. Try a placement to the default queue again.
  9. 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.

Placement rules overview