How to read the Placement Rules table

In the Queue Manager UI you can view all of your placement rules on one page. Learning about this page can help you manage your placement rules according to your needs.

The placement rules overview page is displayed in Cloudera Manager if you select the Queue Manager UI and then go to the Placement Rules tab. It displays a table with the following columns:

Table 1. Placement rules overview page
Column Name	Description
Order	Placement rules are evaluated from top to bottom. This column provides the order of the placement rules.
Type	Indicates to the engine what the current rule should be matched against: application, user, or group. Values: `Application`, `Users`, `Group`
Match	The string to match, or an asterisk "" which means "all". For example, if the type is User and this string is "hadoop" then the rule will only be evaluated if the submitter user is "hadoop". The "" does not work with groups.
Policy	Pre-defined or custom policies which defines where the application should be placed. Values: `User`, `PrimaryGroup`, `PrimaryGroupUser`, `SecondaryGroup`, `SecondaryGroupUser`, `ApplicationName`, `Specified`, `Reject`, `DefaultQueue`, `SetDefaultQueue`, `Custom`
Parent Queue	In the case of `User`, `PrimaryGroup`, `PrimaryGroupUser`, `SecondaryGroup`, and `SecondaryGroupUser` policies, this tells the engine where the matching queue should be looked for. For example, if the policy is `PrimaryGroup`, parent is `root.groups` and the submitted's group is "admin", then the resulting queue will be: `root.groups.admin`
Custom Value	It can have two types of values: In the case of the `SetDefaultQueue` policy: The default queue will change from `root.default` to the value of this field. In the case of the `Custom` policy: The value of this field will be evaluated directly by the placement rules evaluation engine, which means that various placeholders such as `%application` or `%primary_group` will be replaced with their respective values.
Create Queue?	It sets the `create` flag and it works differently in weight and in legacy mode. If it is set to `No`, the target queue determined by the placement policy will not be created if it does not exist. That means that dynamic auto child creation will not happen. However, even if it is set to `Yes` it is still not guaranteed that the queue will be created. You also have to ensure that for the specified parent queue the dynamic auto child creation feature is enabled. The following policies do not support the `create` flag: `reject` `setDefaultQueue` `defaultQueue`
Fallback	If the target queue does not exist or it cannot be created, it defines a fallback action. Values: `Skip`, `PlaceDefault`, `Reject`
Actions	Click on the applicable icon to perform actions on the placement rules: Eye: View Rule Bin: Delete Rule